As soon as Beta 1 of the .NET Common Language Runtime (CLR) rolled out, many programmers asked themselves, "Is COM dead?" Although that's a very plausible question because many companies have millions of dollars invested in applications that use COM and COM+ Services, it isn't really the right way to look at the .NET CLR. The .NET CLR is simply a much-needed evolution of COM and COM+. Think of it as the equivalent of when developers shifted their focus from writing DOS-based applications to writing Windows-based applications. COM code, COM+ Services, and .NET code can all get along together, but doing so involves some significant tradeoffs. For example, calling COM components from the CLR involves a performance penalty.
In a perfect world, all developers would port all their existing code into the .NET CLR, and they would enjoy all the benefits of the CLR. The only problem is that such an approach would cost a lot of time and money, and most companies don't have that luxury in today's economy.
One nice thing about the .NET CLR is that the classes developed to integrate with COM and COM+ Services are very extensive and flexible. Microsoft designed them to let developers call into Win32 DLLs as well as COM DLLs. Also, you can place components managed in the CLR in the COM+ Catalog to participate with COM components that are in the COM+ Catalog. The managed components can then take part in transactions, role-based security, and all the other services that COM+ offers. In the future, I'm sure that Microsoft will roll into the CLR all the services that COM+ offers, but in the meantime, we can still use COM+ if we need to.
The Transition Options
The general rule of thumb of whether to develop applications in .NET is this: If you're building a new application from scratch, .NET CLR is the way to go because the .NET CLR class libraries are very rich and abstract many things that used to be fairly difficult to program (e.g., multithreading, remoting). However, for an existing application, porting part or all of the code to a .NET language and CLR libraries might or might not be worth the time and effort. If performance is a key factor in your application, it would make sense to bring all your code into the .NET CLR. But if you're simply adding to an existing COM-based application, it might make sense to just leave it as is, and expose the COM components as CLR components. That way you can call all your existing COM components in your application from the CLR, for a small performance penalty.
There is no correct answer, but the bright side is that we have many options, and in this economy, that's a good thing.