CODEWITHSUNDEEP
c#c++.netcominterop
TCS
TCS

Reputation: 5890

C# COM-Interop dll for C++ COM dll doesn't work between 2 solutions

I am trying to reuse an interop DLL that compiled in one project on another, and it doesn't work.

I'll elaborate:

The problem is RemoteComClient.dll tries to load native_com_object.dll it MUST use its own Interop. If I try to use the LocalComClient.dll Interop .Net fails to load the assembly.

Edit: The exact exception message I am getting is:

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

Of course the problem also occurs vice-versa (LocalComClient cannot use RemoteComClient's Interop).

My first question is - why?? As far as I understand it should generate the same interop (which obviously I am wrong).

My second question is, is it possible to make one interop for all the .Net clients of the DLL?

I'll point out I am using VS2013 (both machines), the C# objects are AnyCPU, and the C++ is x64.

Important EDIT: I cannot embed interop types because the C# projects are .Net 3.5 (not 4).

Upvotes: 1

Views: 502

Answers (1)

Hans Passant
Hans Passant

Reputation: 941218

The located assembly's manifest definition does not match the assembly reference.

Very common exception message, the DLL it finds at runtime isn't the same as the reference assembly your program was compiled with. A very basic DLL Hell problem, not otherwise specific to COM interop.

You diagnose these kind of failures with Fuslogvw.exe, its trace for the failed assembly bind shows you what it looked for and what it found. The usual mismatch is the version number, you compiled your program with the 1.0.0.0 version of the interop assembly. That version is generated from the type library version number of the COM server. You were using version 1.0, kaboom if the COM server changed and you use its newer interop assembly.

And the PublicKeyToken can easily be a mismatch, you expect the interop DLL not to have one. Kaboom if the one you load at runtime does have one. Not terribly uncommon in COM interop, you tend to favor them getting stored in the GAC and that requires a strong name. Something you usually do later, forgetting to rebuild the app is an easy mistake.

The solution is to rebuild the client app with the correct interop assembly.

Upvotes: 1

Related Questions