I have an Interop dll that was generated by Visual Studio for a third-party COM object that I am consuming in a .NET dll.
I have registered both my consuming dll and the Interop dll in the GAC. I have to use the GAC because these DLLs are being used by a SharePoint 2010 workflow.
When the execution gets to the point where my dll calls the Interop dll the following error was thrown” “Could not load file or assembly” … “The system could not find the file specified” together with the expected version and public key.
If I examine the Fusion Assembly Binding Log Viewer, the following error is listed in the log entry of the Interop dll:
LOG: GAC Lookup was unsuccessful.
I can see that assembly in the GAC, and it has the correct version and public key token as specified in the FileNotFound exception.
What’s going on?
The solution is to compile the Interop yourself: 1 - Unregister your dll and the Interop from the GAC. The /machine:Agnostic causes the Interop to be built targeting the MSIL Processor Architecture, which is the same as my dll. 6 - Add a reference in your project to the new Interop.
To get information on the the assembly attributes (Version, Culture, PublicKeyToken), run the gacutil /l command which will return a list of all the assemblies in the GAC. You can also see the information associated with a particular assembly using the -l parameter.
Http 5.2. 0.0? In summary if you get the "Could not load file or assembly error", this means that either your projects or their references were built with a reference to a specific version of an assembly which is missing from your bin directory or GAC.
The problem is that, as well as Version and Public Key being valid, the Processor Architecture of the Interop must match that of your calling DLL. And, of course, the Target Framework must be the same version.
My dll was compiled to the MSIL (Agnostic, AnyCPU) processor, but for some strange reason Visual Studio insisted on compiling the Interop to x386.
(Maybe this wouldn’t normally cause an issue, but my SharePoint server is 64 bit, which may have caused the symptoms to appear).
The solution is to compile the Interop yourself:
1 - Unregister your dll and the Interop from the GAC.
2 - Start the Visual Studio Command Prompt of the Visual Studio version that relates to the .NET framework your dll is targeting (i.e. I was developing my dll in Visual Studio 2010, targeting .NET 3.5. To do this step I needed to start the Visual Studio 2008 Command Prompt)
3 - Generate the Interop using Tlbmp
tlbimp <full path and filename of COM .tlb> /out:c:\.\Interop.CoolThirdParty.dll /keyfile: <full path and filename of snk> /machine:Agnostic /Namespace:CoolThirdParty
The /machine:Agnostic causes the Interop to be built targeting the MSIL Processor Architecture, which is the same as my dll.
4 - Remove the old reference to the Interop in your dll project
5 - Delete the old Interop file and replace it with the one that you have just generated (e.g. c:.\Interop.CoolThirdParty.dll)
6 - Add a reference in your project to the new Interop.
7 - Rebuild
8 - Register your newly build dll and the new Interop in the GAC
It should start working.
Close Visual studio.... delete all folders from C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files
This should solve your problem....
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With