I am getting invalid cast expception when i am trying to cast the e.BusinessObject

AccountAddresses accountAddressBO = accountAddressBO = (AccountAddresses)e.BusinessObject;

I have attached few images to show the listview settings and events.

Thank you,

Ruchika.

This is actually a .NET message and it can come from a number of different places. The most common is having more than one version of the assembly that has been built or that is in the GAC. Or at times, an old version sticking around in a bin or obj folder.



The first thing to do make sure that you don't have multiple versions of the same assembly in the GAC. Next, I recommend cleaning the solution and then doing a rebuild (not a build). After this, get out of VS and come back in and build again. This ensures that you don't have that assembly hanging around in the AppDomain of VS.



But it will most likely be along these lines that you are experiencing the casting exception since the versions appear to be the same assembly and namespace.

Hi Trent,

Thank you for the quick reply. I have tried all of these with no luck.

Well, I have experienced this before, and to date, every time that I have seen a casting error where the two sides appear to be identical, it has been one of these types of issues. As you can understand, there is nothing past this that I can do other than explain how this type of exception can occur.



One thing that you can do also, is place a break point before you cast it, and then use reflection to see the source location of the file.







This will show you the physical location of the loaded assembly. You may also look at the full name as well to make sure that it lines up.



If all else fails, clear off your local working folder, and re-gather the entire solution from source control....that will most definitely clean out the local folder.

Hi Trent,



I was able to reproduce this issue on my machine.

Then I wanted to try a few different things; I created a new project and added business object to the project itself as opposed to another class library project. And interestingly enough that worked. But as soon I added this BO to another class library project, and referenced it from the Web App, this error occured. And it looks like this issue is specific to ASP.NET app. It will be interesting to see if you could reproduce this on your machine. Given this new information, do you have any ideas to what might be going on here?



Thanks

Yeah, this sounds similar as to what I was referencing. It is a reference issue. These are not always straight forward and the project structure and development environment always plays a factor. You are welcome to create a sample and post it that reproduces the behavior. But if this isn't possible then it will most definitely require troubleshooting on your side.



Just FYI, I know that this logic will work on ASP.NET as we have done this very thing recently on a combo population. But at any rate, if you can reproduce a sample, then that would be great, otherwise it is all shooting in the dark.

Hi Trent,

I have created and attached a sample project to reproduce the problem.

Regards,

OK, this one took me a few minutes to figure out. First of all, if you actually deployed the project, it would work. So if you took exactly what you have and ran it through IIS or a test or production server (outside of the ASP.NET Development Server that runs out of VS in your system tray) it would work and will work.



The problem that you are running into is a .NET issue as to how it pre-compiles the application to run in a debug mode (good news is ahead so don't worry ), it dumps all assemblies into the Temporary ASP.NET folder (i.e. C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files) each time the app is run from within the VS environment. So when you create a reference to an assembly in code, it will shift the references and pull from this temporary ASP.NET files location. But StrataFrame (i.e. the ListView) uses a true resolution (ITypeResolver interface implemented in the ApplicationBasePage) to pull the assembly from the deployed Bin folder (or other sub folder within the compiled application).



So here is what happens when running through the designer:







where as our logic pulls it from the Bin folder (which is far safer in the long run):







Now long term we may make a change to determine if we are running through the designer...but there is a really simple workaround. Just sign the business object library and put it in the GAC on your development machine. You will NOT need to do this when you deploy (nor is it recommended), but this will resolve the casting exception that you are getting and always ensure that you are on the same reference.



You will also want to add a PostBuild Event that throws the BO library assembly in your GAC for you automatically so you don't have to worry about it every time you build. Just use the GACUTIL to automatically add (and overwrite) your assembly into the GAC on the post build event and from that point forward you should be good to go.



One final thought is to call the pre-compile tool on a post-build event and force the output to a totally different location, but this approach could be more cumbersome.

Hi Trent, It all makes sense.

Thank for looking into this.

No problem...sorry for the delay...it took me a few minutes to see from where the assemblies were being pulled before I realized what was going on.