AaronLST

"Could not load file or assembly 'Interop.TraCSFLCom, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b889c5ddf670cf7a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)"

I have remove references to the VB COM DLL from the .NET solution, rebuilt the VB DLL, cleaned the .NET solution, and readded the references to the VB DLL, but I still have this problem. I don't understand what is going on and how this problem cropped up.


Re: Common Language Runtime Interop to VB DLL fails to load

AaronLST

When it automatically generates the Interop.TraCSFLCom.dll, why is it always version 3.5 Why doesn't it reflect the version of the VB DLL




Re: Common Language Runtime Interop to VB DLL fails to load

nobugz

Sounds to me like you have an older version of the COM component floating around in your registry. When you add the reference, pay attention to the Path column in the dialog to find the older version. You can remove it with Regsvr32.exe /u path if the DLL is still there. If it isn't, you'll have to remove the registry entry in HKCR\TypeLib by hand. VB6 also tends to be flaky with registering when you build the component. Forcibly register it with Regsvr32.exe path.

Another failure mode is side-by-side DLLs or registration-free activation. You might have built the wrapper for a version that's registered but are loading another version, either in the same folder as your .exe or as specified in a manifest. Ah, the joys of DLL hell.





Re: Common Language Runtime Interop to VB DLL fails to load

AaronLST

I had a feeling it might be something like that, but I didn't know where that registry information was at. I'll take a look there and mess around. Thanks.




Re: Common Language Runtime Interop to VB DLL fails to load

AaronLST

Ok, I looked up the GUID for the typlib using oleview, found that guid in the registry, and deleted the entire entry, then recompiled the VB dll(which registers it in the process). I removed the references in the .NET project, cleaned, re added references, rebuilt.

Now it works. So thanks alot. I just hope it doesn't suddenly stop working again.






Re: Common Language Runtime Interop to VB DLL fails to load

AaronLST

Ok, I'm not sure why it worked that one time. But after re building my installer, I isntalled on a different machine and it didn't work. I came back to my dev machine and found that it wasn't working anymore. I enabled the fusion log and pasted it below.

I unregistered the VB dll, and pretty much did a search of my entire computer and made sure every instance of that dll was deleted, then searched my registry and deleted all the entries that it referenced. Removed all references in the .net project(also I verified that my COM component wasn't available under the Add References dialog to ensure nothing was left), cleaned the .NET solution, rebuilt the VB dll, added references to the .NET project, rebuilt the .NET project, and then ran it to produce the below.

I have TraCS.FL.Common .Net DLL and a the windows form project, both of which reference the VB DLL. This exception so far only occurs on a certain function call to the Tracs.Fl.Common assembly, which in turn creates an instance of a class from the vb dll and attempts a method call on that class. During debugging, the exception occurs on trying to enter the method in the .Net DLL, which would have then in turn called the VB DLL.

This is a nightmare. There are too many mysterious things going on. If I add a reference and explicitly browse to a DLL, it would seem that it should use that as the dll from which Interop is generated. I may not necessarily have the correct DLL registered in my registry on my dev machine. It seems silly to use that information during compilation.

See the binding log below. Thanks in advance.

************** Exception Text **************
System.IO.FileLoadException: Could not load file or assembly 'Interop.TraCSFLCom, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b889c5ddf670cf7a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'Interop.TraCSFLCom, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b889c5ddf670cf7a'
at Tracs.Fl.Common.Miscellaneous.OpenFormInTraCS(String productKey, Boolean edit)
at Tracs.Fl.FormsMessenger.MessageListener.viewForm_Click(Object sender, EventArgs e) in C:\SourceSafe\TracsFlFormsMessenger.root\TracsFlFormsMessenger\MessageListener\MessageListener.cs:line 1016
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

=== Pre-bind state information ===
LOG: User = DEVELOPMENT\ashumaker
LOG: DisplayName = Interop.TraCSFLCom, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b889c5ddf670cf7a
(Fully-specified)
LOG: Appbase = file:///C:/SourceSafe/TracsFlFormsMessenger.root/TracsFlFormsMessenger/MessageListener/bin/Release/
LOG: Initial PrivatePath = NULL
Calling assembly : TraCS.Fl.Common, Version=1.0.2715.28525, Culture=neutral, PublicKeyToken=b889c5ddf670cf7a.
===
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Post-policy reference: Interop.TraCSFLCom, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b889c5ddf670cf7a
LOG: Attempting download of new URL file:///C:/SourceSafe/TracsFlFormsMessenger.root/TracsFlFormsMessenger/MessageListener/bin/Release/Interop.TraCSFLCom.DLL.
WRN: Comparing the assembly name resulted in the mismatch: PUBLIC KEY TOKEN
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.



************** Loaded Assemblies **************
mscorlib
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
MessageListener
Assembly Version: 0.2.2715.28526
Win32 Version: 0.2.2715.28526
CodeBase: file:///C:/SourceSafe/TracsFlFormsMessenger.root/TracsFlFormsMessenger/MessageListener/bin/Release/MessageListener.exe
----------------------------------------
Microsoft.VisualBasic
Assembly Version: 8.0.0.0
Win32 Version: 8.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/Microsoft.VisualBasic/8.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll
----------------------------------------
System
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Windows.Forms
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System.Drawing
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System.Runtime.Remoting
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Runtime.Remoting/2.0.0.0__b77a5c561934e089/System.Runtime.Remoting.dll
----------------------------------------
System.Configuration
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
System.Xml
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
TraCS.Fl.Common
Assembly Version: 1.0.2715.28525
Win32 Version: 1.0.*
CodeBase: file:///C:/SourceSafe/TracsFlFormsMessenger.root/TracsFlFormsMessenger/MessageListener/bin/Release/TraCS.Fl.Common.DLL
----------------------------------------
c6_yjqdf
Assembly Version: 0.2.2715.28526
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Data
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_32/System.Data/2.0.0.0__b77a5c561934e089/System.Data.dll
----------------------------------------
Tracs.Fl.TransCommExporter
Assembly Version: 0.2.2715.28525
Win32 Version: 0.2.2715.28525
CodeBase: file:///C:/SourceSafe/TracsFlFormsMessenger.root/TracsFlFormsMessenger/MessageListener/bin/Release/Tracs.Fl.TransCommExporter.DLL
----------------------------------------
Interop.TraCSFLCom
Assembly Version: 3.5.0.0
Win32 Version: 3.5.0.0
CodeBase: file:///C:/SourceSafe/TracsFlFormsMessenger.root/TracsFlFormsMessenger/MessageListener/bin/Release/Interop.TraCSFLCom.DLL
----------------------------------------
System.Transactions
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_32/System.Transactions/2.0.0.0__b77a5c561934e089/System.Transactions.dll
----------------------------------------
System.EnterpriseServices
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_32/System.EnterpriseServices/2.0.0.0__b03f5f7f11d50a3a/System.EnterpriseServices.dll
----------------------------------------
ICSharpCode.SharpZipLib
Assembly Version: 0.84.0.0
Win32 Version: 0.84.0.0
CodeBase: file:///C:/SourceSafe/TracsFlFormsMessenger.root/TracsFlFormsMessenger/MessageListener/bin/Release/ICSharpCode.SharpZipLib.DLL
----------------------------------------
Accessibility
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/Accessibility/2.0.0.0__b03f5f7f11d50a3a/Accessibility.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.







Re: Common Language Runtime Interop to VB DLL fails to load

AaronLST

Well I think I got it fixed, again. Just for future reference:

I notice the reference to TraCSFLCom from the Common project, and the reference from the windows form project differ by the Strong Name flag. Since there is only one instance of Interop.TracsFlCom in the output directory, then this was the problem. I.E. the one copy of the interop dll is the one for the windows form project, and the thus the .Net dll fails to bind to this one because it is expecting a strong named.

My main project did not have code signing, so it was not strong named, and thus did not require referenced assemblies to be strong named, and thus it did not generate the interop assembly as a strong named assembly. But the .Net DLL generated a strong named Interop DLL since it requires all referenced assemblies to be strong named.

I could have saved 3 days of pulling my hair out if the exception was a little more informative and said "Failed to load assembly, Interop.TracsFLCom.dll is not strong named."

Or if all Interop DLLs were always generated strongnamed, since a non-strong named project can reference strong named dlls, then I think this would eliminate the chance of this problem occurring. Not sure if it would create more problems though. I guess it might not know what to sign it with though. I can only guess that the VS used my certificate to sign the interop DLL as well as the .Net dll. It would be nice if the reference showed the command line parameters it uses with tlbimp so I knew what mysterious things it was doing automatically.