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.