COM to .NET and .NET To COM

When we talk about creating communication between a .NET assembly and a COM assembly:
Scenario 1 : .NET client  to COM.dll  
   Create a interop assembly by
      1) tlbimp.exe  COM.dll   ( which contains a type library)
      2) The tlbimp.exe command creates an interop assembly based upon the type library  in COM.dll. Let's call that Interop assembly Interop.dll
      3) Then we add a reference to .NET Client project -selecting Interop.dll as our reference.

OR 1) more simply We can directly create a Interop reference simply by using Visual Studio - Add Reference to the COM.dll ( which will automatically extract the type lib and creates the interop assembly)
Scenario concerning COM client   to .NET
 Using  the .NET dll let's call it myNet.dll:
   1) execute Regasm.exe  myNET.dll to register the myNET.dll public classes
   2) Now a COM client can communicate with the  myNET.dll
   1)Simply Register myNET.dll using Visual Studio's - Selecting Build Tab- Register For COM Interop check box) and build the project myNET. This should automatically register the public classes of the .NET module myNET.dll

In both scenarios: Are we essentially creating a code stub ( inter-op assembly) for both scenarios to communicate with the original COM.dll and myNET.dll respectively. Meaning after all that setup the original dlls still need to be present to communicate to?

Results Diagram:
.NET Client --> Interop.dll -> COM.dll
COM Client --> Interop.dll -> myNET.dll

Why do I ask this question? Well in my MCTS 70-536 exam book, it talks about in the case of COM to .NET. In that case it says the  command Regasm.exe myNET.dll registers the public classes contained in myNET.dll so a COM client can talk to it. Isn't it really registering the interop.dll so COM client will communicate with myNET.dll? The Interop.dll being the communication stub between them. And the same for .NET to COM?
Lawrence AverySystem DeveloperAsked:
Who is Participating?
Jacques Bourgeois (James Burger)PresidentCommented:
The interop is necessary only when .NET communicates with COM. It is not only a stub, it also performs a few functions such as converting the format of the dates which is different between .NET and COM.

By the way, with framework 4.0, there is also the option of embedding the Interop types into the .NET application so that one can get rid of the interop file. See Embed Interop Types in the Properties window when you are in the Reference tab.

When Microsoft conceived .NET, they were aware that we would need that feature and they provided the interop as a way for .NET applications to communicate with COM applications.

The other way around, since COM was designed before .NET, it has no awareness of what .NET is. So they designed the thing another way. My understanding is that when you activate the Make assembly COM-Visible option, the compiler creates into the application classes that do the reverse, such as translating dates from the .NET format to the COM format. These are the classes that are registered and exposed to COM applications. So, in some way, the interop is then built into the .NET application.
Lawrence AverySystem DeveloperAuthor Commented:
Great answer again. I think what threw me is what I read in my MCTS -Exam book; the statement registering classes versus assembly.  What came to mind is where are those classes resident after the Regasm.exe is performed?

Thank you.
Lawrence AverySystem DeveloperAuthor Commented:
Just a comment about calling a COM.dll from a .NET client. My MCTS Exam book mentions that you can call a COM.dll by creating prototype methods using the DllImport attribute beside what we just discussed.  However, the book shows an example only using the DllImport attribute when you .NET client is talking to a Flat dll.  Sometimes authors can confuse you. Is that true that a DllImport attribute in your .NET client can call a COM.dll?
I believe the DllImport is called P/Invoke.
Jacques Bourgeois (James Burger)PresidentCommented:
I have never heard of using COM through DllImport. But I never heard that it is not possible either. So I cannot say.

According to the documentation, "You apply this attribute directly to C# and C++ method definitions". You can create COM dlls with other languages than C and C++

And if it is possible, But it would be a very limited way of working.

Also according to the documentation, "You cannot use methods that require an instance of a class". Only static/shared methods. Since most uses of COM is through objects, it would not be very useful.

And marshalling is not supported so it would not make the corrections such as the date formats I talked about sooner.

And it requires more workd from the programmer.

So, if it is possible, I do not see the point.
Lawrence AverySystem DeveloperAuthor Commented:
Maybe while writing the book, their proofreaders somehow overlooked the statement. Anyway, I definitely agree with what you have said about DllImport attribute.
Thank you for the great effort you have made in clarifying COM to NET and NET To COM.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.