C# Type A cannot be casted to Type B ( InvalidCastException)... Context hell?

Question

I'm having a very unpleasant issue with my webapp.

The app is designed as follow :

• The root App is loading a Flex SWF, which in turn loads a 3rd party Flex SWF module in a sub app (MagickECB).
• Both Apps reference Albums.dll, dll found in /bin and /MagickECB/bin and both Apps share the same Application Pool in IIS.

EDIT : That's two projects, the root app project and the subapp project. Subapp project reference root app project.

When loading the sub app's flex module from the root app's flex application, we randomly get a cast error as follow :

There was an error getting configuration of Photobook: [A]Albums.LocalizationConfiguration cannot be cast to [B]Albums.LocalizationConfiguration. Type A originates from 'Albums, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' in the context 'Default' at location 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\magickecb\4414db97\126f5aaf\assembly\dl3\cf281292\4a6ecec8_8a7bcb01\Albums.DLL'. Type B originates from 'Albums, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' in the context 'LoadFrom' at location 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\magickecb\4414db97\126f5aaf\assembly\dl3\017fab88\a91238d1_7977cb01\Albums.dll'. at Albums.LocalizationConfiguration.GetConfig() at Albums.CGlobal.GetUserLocale(String userHandle)

Trying to investigate this issue, I found out the GetConfig method causing the cast error returned

return (LocalizationConfiguration)ConfigurationManager.GetSection("Localization/Localization");

The section in the Web.config is declared as follow : (EDIT : root app's web.config)

<sectionGroup name="Localization"> 
    <section name="Localization" type="Albums.LocalizationConfigurationHandler, Albums"/>
</sectionGroup>

My guess would be that the internal code of GetSection tries to load Albums.dll in the "LoadFrom" context and therefore cause a conflict with the original Albums.dll loaded in the /bin path (see context problematics)

I also note that other dlls in /MagickECB/Bin also reference Albums.dll, so I rebuild all projects so that every DLL reference the same version of Albums.dll

Last, if you check the dll full path in Temporary files, the extensions are different (uppercase vs lowercase)..

Any input on how to solve this problem would be greatly appreciated !!

Solution

Double-check your references, if you compare your two dll locations they are different (extension upper case vs lower case is not an issue):

Temporary ASP.NET Files\magickecb\4414db97\126f5aaf\assembly\dl3\ cf281292\4a6ecec8_8a7bcb01 \Albums.DLL

Temporary ASP.NET Files\magickecb\4414db97\126f5aaf\assembly\dl3\ 017fab88\a91238d1_7977cb01 \Albums.dll

Probably means you're referencing two different files - maybe referencing one as a project and the other directly as a file. Do you have any warnings when you try building your web application regarding references?

EDIT: __AssemblyInfo__.ini file in above folders will give you path from which Albums.dll had been copied.

Comments

[Breakdown]

No warning during compile time. I have two projects, the root app project and the subapp project. Subapp reference root app project.

[xavi]

I was thinking about Albums.dll - how is that referenced in both projects? Is that your project?

[Breakdown]

Yes, both are my projects. I reference Albums.dll (which is the ouput of the root project) in the sub project through Project referencing. Is that what you wanted to know ? (No C/P in the sub app project bin)

[xavi]

OK, have you pinpointed perhaps when is this happening? You said randomly but could it be that this is only happening after IIS restarts, or application not being used for some time, or after pool recycling, rebuild of application ... ? You might also try moving Albums.LocalizationConfigurationHandler into a separate project and reference it from both root and sub project.

[xavi]

One point puzzles me, these both files (Album.dll) are in magickecb sub app, so you must be getting it somehow twice - reference + some other way - still trying to think of how this could happen. Is the call: return (LocalizationConfiguration)ConfigurationManager.GetSection("‌​Localization/Localiz‌​ation"); in root app or sub app?

[Breakdown]

We couldn't pinpoint when the problem is happening. We proceed as follow : stop website, copy dll, restart website. Then, it occurs from 10 minutes to x hours.. the website has little traffic (only from devs). Regarding the double referencing, as I mentionned in the post, I suspect a first reference from /bin auto load and a second one in GetSection which might internaly run a LoadFrom. The mistery is that we never used to have this problem before...

[xavi]

Try another thing, there should be file: __ AssemblyInfo __.ini besides these 2 Album.dlls - I think that's the path from which this shadow copy was made. Go to both folders (...Temporary ASP.NET Files\magickecb\4414db97\126f5aaf\assembly\dl3\ cf281292\4a6ecec8_8a7bcb01 and 017fab88\a91238d1_7977cb01 ) and see if they were copied from the same location

[Breakdown]

By before, I should be more explicit : we used to open, from the root app, an iframe too the context of the second app, in order to launch our flex app. Now, we can load that flex app from inside the root flex app. The blurry thing is that we aren't sure of the timeline (we also integrated on TFS recently).. so we are really clueless on the origin of the error

[xavi]

Have you looked at __ AssemblyInfo __.ini files as I suggested in an earlier comment? Also check in your sub app's .csproj file if you can find any Album.dll occurrences, you should only have a reference to Album.csproj (or whatever your root project's project file name is)

[Breakdown]

I think you got it right.... I looked for the dll in Temporary Internet Files and opened their relative AssemblyInfo.ini... We got 2 different dll from two different path. How ? a temp had backed up some dlls (including Albums.dll) and put them in /bin/backup.... How could I miss that :(.... Tests are to be made but I think it's OK now

[Breakdown]

Confirmed !.. Thanks to you ! :)