Even if your shop has been working with the .NET platform since its inception a year ago, you’re probably still using some legacy COM applications. You may eventually plan to port some or all of these older apps onto the new platform, but how do you handle updating them in the meantime? No one likes writing throwaway code on an outmoded platform.

On the flip side, those COM applications are probably very mature at this point, containing loads of tried-and-true functionality. Logically, you’re going to need to solve many of the same problems with a new .NET version of an application. But most development teams have fewer resources and less time for new projects—not the best situation to be in when you have to reinvent the wheel.

Fortunately, Microsoft went to great lengths to build in functionality to make .NET both backwards and forwards compatible with COM. We’ve written a fair bit on this topic here at Builder.com; these articles can help you make .NET and COM work together more easily.

From COM to .NET…
The most likely programming scenario you’ll deal with is using an older COM component in a .NET application. Time constraints, interoperability with other applications, or even the lack of convertible source code can all conspire to make it more convenient to leverage an older component than to create a new .NET version.

In “COM and .NET interoperability,” S. Vikram explains the differences between the COM and .NET component worlds and shows you how to add COM components to a .NET application, both with and without Visual Studio.NET. You’ll learn about runtime callable wrappers (RCWs) and how .NET adapts COM objects to make them look like native components to an application.

Although .NET represents a huge stride forward for Microsoft developers, it doesn’t provide some of the functionality you’ll find in COM+, such as transactions and just-in-time object activation. “Use COM+ automatic transactions in .NET components,” by Paul Stephenson, shows you how to gain this functionality in a .NET application.

… And back again
Although on the surface it might seem insane to try to use a .NET component in a COM application, there are situations where you might want to do just that, since legacy applications will exist alongside their new .NET counterparts. Building new functionality as a .NET component can make it easier to migrate from COM in the future.

Microsoft has a command-line tool (RegAsm.exe) that you can use to create the type libraries and registry entries needed to consume a .NET component in a COM app. “Backward ‘COMpatibility,’ .NET style” introduces this tool and points out some potential problem areas with using it.

Finally, in “Using .NET assemblies with COM,” S. Vikram shows you how to call code in a .NET class library from a VB6 application. He also discusses COM callable wrappers and the tools Visual Studio.NET provides to make calling COM objects from .NET easy.

Not difficult when you know what you’re doing
Being able to cross the platform boundary between COM and .NET is a valuable capability that can greatly ease your migration headaches. I hope this brief tour of .NET/COM interoperability on Builder.com gives you some ideas about how you can use it in your own applications.

What’s in the future?

What other aspects of interoperability would you like to see covered on Builder.com? Send the editors an e-mail to request that we cover a specific article topic.