CLR Add-In Model

Currently .NET applications have the ability to host add-ins. Isolation and sand-boxing can even be accomplished via AppDomains. However there are some gapping holes in the use case. Microsoft's CLR Add-In Team intends to address these holes in VS 2007.

The CLR Add-In Team divides the issues into two sections. Version 1 problems affect applications the first time they try to add extensibility. Version 2 problems affect applications when their second version is released.

Version 1 problems include:

Activation
Discovery
Isolation
Lifetime Management
Loading/Unloading
Sandboxing

Version 2 problems include:

Backwards compatibility: running V1 add-ins on V2 applications
Forwards compatibility: running V2 add-ins on V1 applications
Isolation changes: moving from AppDomain to Process isolation boundaries
Sharing: taking an add-in built for one application and running it in another

Jack Gudenkauf and Jesse Kaplan of MSDN Magazine covers some of these in their article, .NET Application Extensibility.

Add-ins are built against abstract classes defined by the host. The AddInStore is used to obtain information about available add-ins. Information about add-ins are returned as tokens containing the add-ins' Name, Version Number, Publisher, and Description.

Add-ins can be activated via their token. The activate is a one-line call that takes the security level the add-in will be run under and returns an object that implements the previously mentioned base class. The object actually runs in a separate AppDomain, which protects the rest of the application from failures within it.

In order to unload an add-in, its entire AppDomain must be unloaded. This can be as simple as calling ShutDown on the AddInController.

Like any new framework, the CLR Add-In Model needs a real application to put the design to the test. Jason He is running a series of articles on how to use the CLR Add-In Model to extend Paint.NET. Among other things, these articles go into some of the finer details of an add-in's life cycle.