1

I have created an x86 "wrapper" for an x86 library we have from a vendor. I've been following the steps mostly from this post as well a couple links for calling COM here and here.

I marked the project as "Register for COM interop". I was able to find by COM interface using oleview and marked it as "Use Surrogate Process". So hopefully I'm good to this point as far as the DllSurrogate registry settings go.

Now I can't seem to get the reference correct to consume the x86 COM. Supposedly I can either do a direct reference through COM, or use tlbimp, in order to create the RCW assemblies which I can use from my x64 project.

With a COM reference I get the error "The ActiveX type library was exported from a .NET assembly and cannot be added as a reference."

When I pass the dll to tlbimp I get "error TI1002: The input file is not a valid type library."

When I pass the tlb to tlbimp I get "error TI1029 : Type library was exported from a CLR assembly and cannot be re-imported as a CLR assembly."

Any help on what I could be missing here is greatly appreciated.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
grinder22
  • 551
  • 4
  • 17
  • In the general case, you don't have to program/code/develop anything (just configure) to use an x86 COM "server" from a 64-bit COM "client". You can either use a surrogate or COM+ Component Services (it's also a system's surrogate underneath) which has a UI to quick test: https://stackoverflow.com/a/52602821/403671 (skip the x86 component creation steps of course) – Simon Mourier Mar 17 '20 at 21:29
  • @SimonMourier thanks for the reply. I was hoping to use a hard reference to the RCW (early binding). I'll try the late binding technique described in that post for now and see what happens. – grinder22 Mar 18 '20 at 15:07
  • You can use early or late binding. I used late because it was simpler. To use early binding, you'll need a .tlb that you can reference in the x64 project. – Simon Mourier Mar 18 '20 at 18:20
  • @SimonMourier the late binding worked nicely and I think we will stick with it. I suspect my tlbimp failed on the dll due to a missing dependency. – grinder22 Mar 20 '20 at 17:13
  • late binding is fine as long it suits you (it can be a pain if you have a huge object model). dependencies can indeed cause a lot of issues. You can use the procmon tool from sysinternals to detect what files are searched from. – Simon Mourier Mar 21 '20 at 06:40

1 Answers1

1

Hopefully this will help someone else who lands on this. I was already configured correctly from the COM perspective. From there it really became a question of early binding vs late binding.

Late binding worked well with a few simple lines of code:

var type = Type.GetTypeFromProgID("ProgId");
dynamic o = Activator.CreateInstance(type);
var foo = o.DoSomething();

Early binding means you will need the RCW assemblies to reference. In some cases VS will automatically create these for you when you reference a COM object directly. However in this case of creating a COM from a .Net assembly, then trying to convert from COM back to .Net - VS thinks you are doing something circular and disallows it. tlbimp will give you the similar error if you run it on the tlb file rather than the dll.

In our case we were missing some assemblies down in our wrapper project, which was likely causing tlbimp to fail when called with the dll. But we chose to stick with late dynamic binding due to our trivial little interface.

grinder22
  • 551
  • 4
  • 17