Feb. 15, 2011, 2:43 a.m.
posted by fractal
Migrating to a new development platform can be a painful process. In extreme cases, you might have to throw away the results of years of work when you decide it's time for a new set of tools. This can make switching to a new platform a very difficult decision.
Fortunately, Microsoft recognized the need to provide easy migration paths from previous versions of its tools to the .NET world. In particular, if you heeded the advice to use COM for intercomponent communications and to design your applications as sets of COM servers and clients, you'll find the upgrade path to .NET smoother. That's because the .NET Framework includes good support for interoperating with existing COM-based code.
In Chapter 7, "Component Services," you learned how COM components are able to call the .NET code. The .NET Framework also allows the .NET components to instantiate and call COM components. Combine this with an existing modular architecture and you get an easy migration path: Move one module at a time from COM to .NET, and use the .NET interoperability features so that the components can continue to talk to one another.
In this chapter you'll learn about the facilities that the .NET Framework provides for using COM components and other legacy code. In particular, you'll learn about the tools and techniques that are necessary to call COM components and Windows API code from the .NET Framework.
You may want to use the unmanaged code from a variety of .NET applications such as a Windows service, a serviced component, a .NET remoting object, and an XML Web service. Basically the process of using unmanaged code from all of these applications is similar. I'll use Web services for most of the examples in this chapter; however, you can follow the same process for other .NET applications.