GAC - the assembly is in the GAC, but "cannot load the file or assembly"

Question

I have an Interop DLL that was generated by Visual Studio for a third-party COM object that I consume in a .NET dll.

I have registered both my consumer DLL and the Interop DLL in the GAC. I have to use the GAC because these DLLs are used by the SharePoint 2010 workflow.

When the execution reaches the point where my DLL calls the Interop DLL, the following error was selected: "Could not load the file or assembly" ... "The system could not find the specified file" along with the expected version and public key.

If I look at the Finding Assembly Binding Log Viewer, the following error will appear in the Interop dll log entry:

LOG: GAC Lookup was unsuccessful.

I see this assembly in the GAC, and it has the correct version and public key token, as indicated in the FileNotFound exception.

What's happening?

Answer 1

The problem is that, just as the version and public key are valid, the Interop Processor Architecture must match the structure of your calling DLL. And, of course, the Target Framework should be the same version.

My dll was compiled for the MSIL processor (Agnostic, AnyCPU), but for some strange reason, Visual Studio insisted on compiling Interop for x386.

(Perhaps this usually did not cause a problem, but my SharePoint server is 64 bits, which could cause symptoms).

, Interop:

1 - DLL Interop .

2 - Visual Studio Visual Studio, .NET, dll (.. DLL Visual Studio 2010, .NET 3.5 , Visual Studio 2008)

3 - Interop 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  

/: Agnostic Interop MSIL, dll.

4 - Interop dll

5 - Interop , (, c:.\Interop.CoolThirdParty.dll)

6 - Interop.

7 -

8 - dll Interop GAC

.

Answer 2

Visual studio.... C:\Windows\Microsoft.NET\Framework\v4.0.30319\ ASP.NET

....

Answer 3

I hope your third-party COM object is also registered on the machine

Answer 4

I got this for a line in my webconfig in compilation.assemblies, referring to the assembly that was in the GAC. The problem was that someone put the reconfiguration of the assembly in the redirection of web.config from the version that was in the GAC to some other non-existent version.