UPDATE: This article is now hosted at the .NET Developer Journal site!

There is an increasing amount of discussion around the topic of “.NET Purity” in development circles.  When selling and application the question often arises “is your application 100% .NET?” or “How much of your application is .NET?”  There is an implied qualitative judgment behind these questions and it’s usually pejorative.

The implication is that an application that is entirely written in .NET, presumably without any interoperation with COM or direct calls to the Win32 API, is superior to an application that is a combination of technologies.

Certainly .NET represents a fantastic leap in developer productivity and puts a clean, consistent face on the services that the Windows Platform provides.  For many years the set of interfaces provided by the Windows OS Platform – collectively known as the Windows SDK – have been exposed to developers as exported “C”-style functions in DLLs, and in recent years, via the Component Object Model (COM).

Common Language Runtime or Virtual Machine?

Often the .NET Common Language Runtime, or CLR, is directly compared to the Java Virtual Machine.  Initially, there are many clear parallels: both are “managed” environments that provide a component container, both consume a “partially chewed” intermediate language, both provide low-level services like garbage collection and threading conveniences.  

While these parallels are superficially compelling, these two implementations differ fundamentally in philosophy.  Comparing the CLR to the VM is reasonable only to a certain point – their architectural goals are ultimately different. 

Sun promotes a marketing program called 100% Pure Java, which is certainly appropriate if code portability and underlying operating system transparency is a desirable endpoint.  However, many 3^rd party Java Application Servers create a competitive advantage by judicious use of “C” function calls directly down (via Java Native Interface or JNI) into their host Operating Systems value-added services that are not exposed by the Java Application Platform (the Java Class Library).   Calling into the core platform is the only way to make use of base functionality that is only presented via a native interface!

The Java VM is truly a “virtual machine” that’s ultimate goal is to abstract (virtualize) away the underlying Operating System and provide an idealized (not necessarily ideal, but idealized) environment for development.  The Java Virtual machine is also intimately united with the API – the Java Application Platform, which services provided by the VM implementation.  Regardless of where you run your compiled Java code, you will run within the context of the Virtual Machine and ostensibly link with supplied Java Platform APIs.

The .NET Common Language Runtime is named well as it is used more as a Language Runtime than a Virtual Machine.  While it successfully abstracts away aspects of underlying hardware through its use of an Intermediate Language, when the CLR is combined with the .NET Framework Library of APIs it is married to the underlying platform, which is Windows.   The CLR provides all the facilities of the Windows Platform to any .NET-enabled Language.

.NET Framework Library

The Windows Platform has dozens and dozens of high-level system services that are exposed by thousands of APIs.  This large library of functionality encompasses various levels of richness.  A low-level API may open a file off a disk, while a high-level one might play an audio file.  The designers of the .NET Framework wanted to create a consistent object-oriented face on a rich legacy of platform functionality.  The CLR and .NET Framework work together to expose the capabilities within the Windows Platform, including those that may have previously been hidden away in difficult or little known APIs.

While the CLR provides a new paradigm for application development, it does not close the door on existing libraries.  The CLR provides interop services to the developer but the biggest consumer of these services are the .NET Class Libraries that unlock existing Windows Platform abilities via a  .NET API!

For example, when sending email using the .NET Framework Library class System.Web.Mail.SmtpMail, the Class Library uses a helper class that abstracts the existing CDO (Collaboration Data Objects) COM Library.  This is just one example where a .NET Library developer chose to rely on a production-ready reliable existing library rather than write something from scratch.  This example and dozens of others with the Library not withstanding, the Common Language Runtime still at some point needs to work with the Windows internal APIs.

If Microsoft were to truly virtualize the machine, they would have marginalized their investment in the Windows platform.  Certainly it behooved the designers to make transitions to existing libraries as painless as possible.  They have enabled this with NETàCOM Interop via both Runtime- and COM-Callable Wrappers, the ability to tap into standard Win32 Platform APIs via a technology called P/Invoke (short for Platform Invoke) as well as other options.  When writing code that is hosted in the CLR the vast resources of platform are just sitting under the developer – the runtime is transparent rather than virtual!  This marks a fundamentally different view of the platform that other virtualizing machine implementations. 

While creating a new fresh application using only .NET may offer some benefits in the arenas of deployment or marketing, these benefits may be not realized when weighed against the cost of rewriting non-.NET components in .NET when those legacy components could have been leveraged.  A “pure” .NET solution can only make use of either those pieces of functionality that can be achieve entirely within the runtime, or those functions that have been exposed by the Base Class Library – which itself uses COM Interop and P/Invoke!

The .NET Framework Library itself isn’t “pure .NET” as it takes every opportunity to take full advantage of the underlying platform primitives.   Moreover, the concept of .NET Purity is rendered specious in this new light.  The .NET Framework is the best way to create business components on the Windows Platform, but any applications along with the .NET Framework are only lifted as high as the underlying Windows OS services.

“Hybrid” Solutions provide Real Solutions

Many large existing applications are written in Visual C++ and COM.  They are written “close to the metal” to take full advantage of native Windows multi-threading and fine-grained memory management.  However, new business components may also be written in a .NET language such as C# or VB.NET.  The existing system then hosts the .NET Common Language Runtime within its process space and Interops.  The interface is usually COM interop but only incurs minimal overhead of between 10 and 40 processor instructions per in-proc call. 

.NET Components hosted with in the legacy applicaiton can take advantage of that application's existing services.  Lower level developer features such as memory management, object lifetime and object orientation are provided by the CLR, while higher level vertical-specific business functionality is exposed via the legacy application.

This “hybrid” can provide a best-of-breed solution on the Windows Platform exploiting both the highly performant low-level APIs via C++ and the highly componentized and object oriented features of the .NET Framework.  These solutions can work very successfully while companies migrate their existing code bases to the .NET Framework.