Implications for COM

Does .NET replace COM?

This subject causes a lot of controversy, as you'll see if you read the mailing list archives. Take a look at the following two threads:

http://discuss.develop.com/archives/wa.exe?A2=ind0007&L=DOTNET&D=0&P=68241
http://discuss.develop.com/archives/wa.exe?A2=ind0007&L=DOTNET&P=R60761

The bottom line is that .NET has its own mechanisms for type interaction, and they don't use COM. No IUnknown, no IDL, no typelibs, no registry-based activation. This is mostly good, as a lot of COM was ugly. Generally speaking, .NET allows you to package and use components in a similar way to COM, but makes the whole thing a bit easier.

DCOM dead?

Pretty much, for .NET developers. The .NET Framework has a new remoting model which is not based on DCOM. DCOM was pretty much dead anyway, once firewalls became widespread and Microsoft got SOAP fever. Of course DCOM will still be used in interop scenarios.

Is COM+ dead?

Not immediately. The approach for .NET 1.0 was to provide access to the existing COM+ services (through an interop layer) rather than replace the services with native .NET ones. Various tools and attributes were provided to make this as painless as possible. Over time it is expected that interop will become more seamless - this may mean that some services become a core part of the CLR, and/or it may mean that some services will be rewritten as managed code which runs on top of the CLR.

For more on this topic, search for postings by Joe Long in the archives - Joe is the MS group manager for COM+. Start with this message:

http://discuss.develop.com/archives/wa.exe?A2=ind0007&L=DOTNET&P=R68370

Can I use COM components from .NET programs?

Yes. COM components are accessed from the .NET runtime via a Runtime Callable Wrapper (RCW). This wrapper turns the COM interfaces exposed by the COM component into .NET-compatible interfaces. For oleautomation interfaces, the RCW can be generated automatically from a type library. For non-oleautomation interfaces, it may be necessary to develop a custom RCW which manually maps the types exposed by the COM interface to .NET-compatible types.

Here's a simple example for those familiar with ATL. First, create an ATL component which implements the following IDL:

    import "oaidl.idl";
   import "ocidl.idl";

   [
       object,
       uuid(EA013F93-487A-4403-86EC-FD9FEE5E6206),
       helpstring("ICppName Interface"),
       pointer_default(unique),
       oleautomation
   ]

   interface ICppName : IUnknown
   {
       [helpstring("method SetName")] HRESULT SetName([in] BSTR name);
       [helpstring("method GetName")] HRESULT GetName([out,retval] BSTR *pName );
   };

   [
       uuid(F5E4C61D-D93A-4295-A4B4-2453D4A4484D),
       version(1.0),
       helpstring("cppcomserver 1.0 Type Library")
   ]
   library CPPCOMSERVERLib
   {
       importlib("stdole32.tlb");
       importlib("stdole2.tlb");
       [
           uuid(600CE6D9-5ED7-4B4D-BB49-E8D5D5096F70), 
           helpstring("CppName Class")
       ]
       coclass CppName
       {
           [default] interface ICppName;
       };
   };

When you've built the component, you should get a typelibrary. Run the TLBIMP utility on the typelibary, like this:

    tlbimp cppcomserver.tlb

If successful, you will get a message like this:

    Typelib imported successfully to CPPCOMSERVERLib.dll

You now need a .NET client - let's use C#. Create a .cs file containing the following code:

    using System;
   using CPPCOMSERVERLib;

   public class MainApp
   {
       static public void Main()
       {
           CppName cppname = new CppName();
           cppname.SetName( "bob" );
           Console.WriteLine( "Name is " + cppname.GetName() );
       }
   }

Compile the C# code like this:

    csc /r:cppcomserverlib.dll csharpcomclient.cs

Note that the compiler is being told to reference the DLL we previously generated from the typelibrary using TLBIMP. You should now be able to run csharpcomclient.exe, and get the following output on the console:

    Name is bob

Can I use .NET components from COM programs?

Yes. .NET components are accessed from COM via a COM Callable Wrapper (CCW). This is similar to a RCW (see previous question), but works in the opposite direction. Again, if the wrapper cannot be automatically generated by the .NET development tools, or if the automatic behaviour is not desirable, a custom CCW can be developed. Also, for COM to 'see' the .NET component, the .NET component must be registered in the registry.

Here's a simple example. Create a C# file called testcomserver.cs and put the following in it:

    using System;
   using System.Runtime.InteropServices;

   namespace AndyMc
   {
       [ClassInterface(ClassInterfaceType.AutoDual)]
       public class CSharpCOMServer
       {
           public CSharpCOMServer() {}
           public void SetName( string name ) { m_name = name; }
           public string GetName() { return m_name; } 
           private string m_name;
       }         
   }

Then compile the .cs file as follows:

    csc /target:library testcomserver.cs

You should get a dll, which you register like this:

    regasm testcomserver.dll /tlb:testcomserver.tlb /codebase

Now you need to create a client to test your .NET COM component. VBScript will do - put the following in a file called comclient.vbs:

    Dim dotNetObj
   Set dotNetObj = CreateObject("AndyMc.CSharpCOMServer")
   dotNetObj.SetName ("bob")
   MsgBox "Name is " & dotNetObj.GetName()

and run the script like this:

    wscript comclient.vbs

And hey presto you should get a message box displayed with the text "Name is bob".

An alternative to the approach above it to use the dm.net moniker developed by Jason Whittington and Don Box.

Is ATL redundant in the .NET world?

Yes. ATL will continue to be valuable for writing COM components for some time, but it has no place in the .NET world.