DLL Problems Causing Casting Exception

Question

I've been breaking apart a large VS C# project into smaller projects, and while everything worked fine when it was all one project, I'm getting an error now that I've split it apart. There is an exception being thrown when I try a cast, though I haven't changed any of the code. The exception is as follows:

InvalidCastException
[A]MyApplication.MyProject.MyNamespace.Class cannot be cast to [B]MyApplication.MyProject.MyNamespace.Class. Type A originates from 'MyProgram, Version=2.4.0.46, Culture=neutral, PublicKeyToken=null' in the context 'Default' at location 'c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\rc\78e25ad5\28e4b7d\assembly\dl3\877f6451\b808fef4_4e19cb01\MyProgram.DLL'. Type B originates from 'MyProgram, Version=2.4.0.46, Culture=neutral, PublicKeyToken=null' in the context 'LoadFrom' at location 'C:\Source\view\Application\Version\core\bin\MyProgram.dll'.

As you can see, the two types in the cast are identical, the only differences are the contexts and the locations. A method called GetHelperPage() is the source of the problem - it's an external method in an outside application. This normally wouldn't be a problem except that the external application then calls back to this dll. The method looks like this:

[DllImport("EpsComHelper.dll", EntryPoint = "EPSCOMClientGetPage", CallingConvention = CallingConvention.Cdecl, CharSet = CharSet.Ansi)]
private static extern int HelperGetPage(uint pClient, String sPage, StringBuilder sBuff, int nBuffSize);

This external program has the correct path for the dll: "C:\Source\view\Application\Version\core\bin\MyProgram.dll". However, VS is loading the dll into its temporary files and running it from there as you can see by the path in the exception above. This makes it so its looking in two identical dlls, which is causing the error. I saw the responses at http://stackoverflow.com/questions/777888/reflection-and-casting but i don't have ConfigurationManager.AppSettings["DLL_File_Path"] or Assembly.LoadFrom("path.dll") anywhere in my solution. In fact, Assembly or LoadFrom or the location of the dll are never mentioned in the solution at all in an significant way. All I can think is that this is somehow being done behind the scenes by VS, and I can't find anywhere where I can change it. Any help would be much appreciated.

The call stack for the error:

RedCarpetCore.dll!RedCarpet.Core.EpsInProcess.EpsConnector.ChangeLogLevel(string[] args = {string[3]}) Line 3727 + 0x1d bytes
DotNetBridge.DLL!<Module>.RunMethodInProcess(sbyte* szAssembly = 0x035b7db4, sbyte* szFullyQualifiedName = 0x08ebfcf4, sbyte* szClientPtr = 0x0bccd26c, int nArgs = 2, sbyte** arrArgs = 0x0263190c) + 0x43f bytes
[Native to Managed Transition]
DotNetScriptPlugin.dll!034d9e5f()
ntdll.dll!7c827a29()
kernel32.dll!77e6570a()
MSVCR71.DLL!7c352d9b()
MSVCR71.DLL!7c3531c5()
MSVCR71.DLL!7c352e69()
MSVCR71.DLL!7c36a582()
MSVCR71.DLL!7c34f9a2()
MSVCR71.DLL!7c34f9a2()
MSVCR71.DLL!7c350135()
MSVCR71.DLL!7c36a582()
eprise.dll!01d15fa7()
eprevent.dll!01e218f0()
eprevent.dll!01e2ec73()
eprise.dll!01ccf427()
wcc200.dll!01c0a6c5()
oleaut32.dll!77d04141()
[Managed to Native Transition]
RedCarpetCore.DLL!RedCarpet.Core.EpsInProcess.EpsClient.GetPage(string s = "/sysinfo") Line 318 + 0x1a bytes

You'll notice the dll gets switched somewhere in all the jumble. The dll with the capital letters at the start is in the temporary files and the dll at the end with the lower-case letters is the one in the bin.

Answer 1

When it calls the external program via HelperGetPage(), that program is then also calling back to this dll. It has the path of this dll at C:\Source\view\Application\Version\core\bin\MyProgram.dll, and even though it seems to be finding the correct dll there (as in an identical dll with the same name), it is in fact not the correct dll. The dll in this bin is being generated when that project compiles, but that dll is then copied over to the bin of the main project when it compiles. The path of the correct dll is C:\Source\view\Application\Version\application\bin\MyProgram.dll. Even though the dlls are identical, it's running it from the application\bin folder not the core\bin folder, so that's the dll the external program must access in order to not cause a dll mix-up.