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.

Is 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.