在C中使用C＃dll-托管CLR或注册COM互操作，Visual Studio 2010

Question

As it is described here I'd like to use a DLL in my C program. The first two options I am considering are:

1. Host CLR

My problem here would be the note from this article:

Hosting methods provided by versions of the .NET Framework before the .NET Framework 4 are deprecated. We recommend that you use the interfaces introduced by the .NET Framework 4 and discussed in this topic.

In my case the DLL files are working under the .NET Framework 2.0 so this could be a problem in the first place.

• Does anybody know if I can do this anyway somehow?

2. Register for COM interop

The other option is using COM. In this case I would need to know what exactly does the option Register for COM interop in Visual Studio 2010. The DLL file is part of a library that our company also gives to customers. So what I need to know is:

• Which additional information are stored inside the DLL?
• Could there be a reason why a company would not want to register its DLLs for COM interop?

Thanks for any information!

Answer 1

Using Regasm.exe (aka "Register for COM interop") does two things:

• it records where the DLL is located so it can be automatically found. You just use a number in your own code, a GUID.
• it records which CLR version is required to run the code. You automatically get the right one.

So it solves the exact problem you are trying to solve :) No coincidence of course. Hosting the CLR yourself has the advantage that you can call any .NET code, not just the kind that's [ComVisible]. It isn't otherwise a way to avoid having to learn how to write COM code, the hosting interfaces and the primary .NET interfaces you need to call .NET code (like _Assembly) are also COM based. Using C instead of C++ is cruel and unusual punishment, best avoided.

Answer 2

To answer your question: 1. You definitely can host a 2.0 in your process. Jeffrey Richter recommends using CorBindToRuntimeEx Function in the 2.0 edition of his CLR via C#. This got deprecated in the latest versions of the framework, hence the confusion. I would recommend going this way.

2. COM interop - to make it work properly you actually need to change your library, add some attributes, then register the resulting COM object, etc. I am pretty sure it adds references to some marshallers and other COM related stuff. I would definitely stay as far as possible from COM. The shortcomings of this technology was one of the reasons to come up with .Net in the first place. And even more so if you ship these dll's to anyone.