C# versus COM

C# versus COM

• Io2006

  In the context of the language itself.

  For example, some third party software vendors give you a C# api or a Java api to their product, when really all that is happening, at least in the Java api, is JNI making calls to COM components.

  Is C# it's own language, or is it just another layer on top of COM, which happens to benefit from a CLR, aka .NET runtime.

  
  
  

• DragonC#

  My take.  .NET is a complete replacement to COM, but they share many traits in common.  Its metadata support is like COM typelibs (but more powerful of course) to represent types.  CLR also introduces a bytecode (called IL) used to encode the program itself.  The C# compiler outputs this bytecode and metadata, called assemblies.  These assemblies are consumed by the CLR (Common Language Runtime), which is analagous to the Java VM.

  The IL is orthagonal to the language used to produce it.  There are lots of other .NET language compilers out there, and their implementations are based on common spec (CLS).  These compilers include C++/CLI and VB.NET (the other two of the three main .NET languages), and F# and IronPython in the "open" domain. 

  COM interoperability is layered on top of .NET.  This lets .NET applications call COM objects in the same way VB6 does--through the IDispatch interface.

  Under the hood, the CLR is responsible for loading assembies, JITting them to native code, and running them.  This does involve loading DLL's but its the metadata and IL that the CLR is after, not CoCreateInstance and IDispatch in the COM world.

  So no, COM is not used in .NET other than to provide backward compatible interoperability.  The CLR is a completely new runtime environment.  If COM were the substrate upon which CLR rested, then I don't think you would see the kind of performance gains that you see when you compare, for instance, .NET apps vs. Java. 

  Brian

   

   

  
  

• anubisascends

  "Does the CLR rely on existing COM components to "translate/interpret" the bytcode "

  Nope.  The JIT compiler that is part of the CLR consumes IL from assemblies and outputs native code that is executed directly.  If your .NET component is calling into an old COM object (coded in C++ usually), it is done through an interop layer that isn't really part of the CLR.  (It's part of the .NET base library.)  If you are really interested in how this is done, I can try to find good lit on it.

  "How can interpreted IL(bytecode) have faster performance than native C++ COM Components "

  First, the IL is not interpreted by the CLR.  IL is compiled to down native by the CLR (and cached away) at runtime.  On average, CLR-generated code quality is not as good as those by the native Microsoft C++ compiler, but it's pretty darn good.  (In fact there are some scenarios where JIT-compiled code outperforms natively-compiled code due to the efficiencies of the garbage collecting memory allocator.)

  COM components have two kinds of interfaces: C++ vtbl-based and IDispatch, which is what VB uses.  The vtbl interface is used by C++ clients since 1. the compiler already knows how to generate code to call functions directly, and 2. has the C++ header that describes the vtbl.  .NET only has the typelib built (as a resource) into the dll, and thus has to use a method similar to IDispatch.  Here's but one article that covers COM interop in .NET: http://samgentile.com/blog/articles/362.aspx (Its my understand that it's a hybrid: you still marshall data to and from the COM object, but the RCW uses the vtbl to make the jump rather than calling IDispatch->Invoke).

   

   

  
  

• clstephenson

  In what context Sometimes it may use pre-existing DLLs and use COM to communicate with them (MSHTML for examle).
  
  

• Ravel

  I'm not sure what you're looking to answer. Yes, C# is it's own language. It's structure more-or-less depends on being compiled for use an a CLI/CLR. You can write an application in C# that does not use COM, if that's what you're asking. The language itself has no direct dependence on COM--it's just a language. If your particular application needs to be accessible via COM then you'll have to take into account some COM attributes for it to work properly; but the implementation of that is all done via the CLR, not through the language.

  
  
  

• txteacher

  Thank you both, Brian and Peter for your replies.

  I think I have an answer to my question when I read that .NET is a complete replacement to COM, but at the same time I'm still a little confused about why I would want to use existing COM components in C#, if all of those COM components were replaced by C#.

  I guess my question is now this: The C# compiler produces the IL (bytecode) and that bytcode is interpreted by the CLR. Does the CLR rely on existing COM components to "translate/interpret" the bytcode

  >>So no, COM is not used in .NET other than to provide backward compatible interoperability. The CLR is a completely new runtime environment. If COM were >>the substrate upon which CLR rested, then I don't think you would see the kind of performance gains that you see when you compare, for instance, .NET apps >>vs. Java.

  How can interpreted IL(bytecode) have faster performance than native C++ COM Components

  If this is hijacking the thread, I apologize. I can post a new thread if necessary.

  
  
  
• C# versus COM