Why Customize the .NET Common Language Runtime?

The user double-clicks on a .NET program. The CLR loads it and runs it. Works like a champ. Why would anyone need to customize the .NET Runtime?

In fact, there are several good reasons. Access to the debugging API is one. Low-level monitoring of things like garbage collection is another. But the most important reason for many developers is the creation of robust extensible applications. In addition to running their own code, extensible applications run code provided by the user. Any mishandling of memory or security could, in principle, damage the entire application. The user library which extends the application needs to be carefully managed. Experienced .NET programmers know that the unit of isolation for memory management and security within .NET is the AppDomain, much as the process is the unit of management within the operating system. The .NET 2.0 runtime provides new interfaces which permit developers to provide their own customized AppDomain management. While the CLR must be launched using unmanaged code, a custom AppDomain manager for version 2.0 can be written in C# or your favorite .NET language.

One example of an program which uses a customized CLR is Microsoft’s SQL Server 2005. If a stored procedure or function is implemented as .NET code, that code cannot be allowed to request memory from Windows. Any server expected to run 24/7 must manage its memory very carefully, and SQL Server cannot have memory being requested behind its back, so to speak. The customized CLR running .NET code within SQL Server routes all requests for memory through SQL Server rather than to the OS directly, thereby ensuring that SQL Server can manage its memory successfully. A service or application which loads the CLR into its own process to run managed code is said to host the CLR.

Of course, it is not only mission-critical server database systems which need to make use of such features. Imagine a small financial services firm which provides software for its customers’ use. Some of the customers are quite sophisticated and request special features. Of course, each customer requests a different special feature. One solution to this problem is to make the core application extensible. Special features can then be implemented as add-ins, vastly simplifying the management of the core application’s development.

This will be the scenario for our exploration of the .NET runtime and its customization. We will start by examining how the CLR loads and runs a simple program.