Customizing 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.