Chapter 11: Unmanaged Interoperability

COM is Love.
— Don Box

I have a feeling that very little software written today, except for some FORTRAN programs, will be in use anywhere near AD 3400, but I have faith that Windows 2000 should have shipped by that time.
— Dale Rogerson

Overview

If it isn't evident by now, the term managed code refers to any code that executes under the control of the CLR. In other words, things which begin life as C#, VB, C++/CLI source (or one of the many other languages available) and whose compiler transforms the high-level code that you write into metadata and IL. Of course, the CLR's JIT then turns this into its native equivalent, making use of several managed services such as the GC and security along the way. Unmanaged code, on the other hand, does not have such a rich lifetime. It can indeed execute in some form of structured container or management infrastructure — COM is a great example of that — although the two worlds are generally quite different and distinct. Regardless of how great we like to think managed code is, one fact still remains: a lot of code has been written using unmanaged technologies such as C++, Win32, and COM, and is still living, breathing, and doing quite well out there in the world.

It's not a very cost-effective proposition to spend months (or years) on a monolithic rewrite project to port an entire application from unmanaged to managed code. These are usually those massively costly projects that you always hear about failing after months and months of hard work, costly checks, and early warning signs that perhaps the project was doomed from the beginning. Yes, old code is old, is perhaps difficult to extend, and in some cases requires specialized expertise to maintain. But such codebases have probably survived through years of bug fixes and maintenance. In other words, it's mature. It'd be a shame for your company to blindly throw away and not leverage those existing assets.

Furthermore, some applications are better suited to using unmanaged code for some components, especially those with demanding memory management requirements. For example, most high-end games need to manage memory very tightly to ensure good frame rates; many scientific applications similarly must work with raw memory segments due to the sheer magnitude of maps, reduction, and massive memory calculations and manipulation.

But at the same time, other components of these same programs would benefit greatly from managed code. Games have large amounts of AI and character-scripting components; the authors of that style of logic probably don't care much about memory management, and hence a Garbage Collected execution environment and a managed scripting language would make their lives much simpler. Similarly, a scientific application might use the UI for data visualization; the complex calculations in the background might utilize unmanaged code, while Windows Presentation Foundation, WinForms, or ASP.NET could be used to develop the UI and input components. (They sure beat MFC.)

Fortunately, the .NET Framework enables bidirectional interoperability with C++, Win32, and COM. This means that you can continue to leverage those existing valuable assets while still investing in the future and building on top of a rock solid managed execution environment. You might be surprised at the level of integration the runtime supports. In fact, the designers and architects of the CLR knew up front that enabling existing customer code to continue running was very important. Web services are yet another technique for interoperating with legacy code, albeit one strategy not discussed in this book. This chapter takes a look at some tools, technologies, and techniques necessary to take advantage of the rich unmanaged interoperability found in the CLR and .NET Framework.