We’re a new feature team in the CLR that is tasked with making it easy for managed applications to host add-ins (and plug-ins, add-ons, extensions, ...) .  These features will first be included in the Orcas version of Visual Studio and the .Net Framework and most of our features are in the latest Orcas CTPs available here:  VPC, self-extracting install.  

There are two classes of problems we’ll be addressing with these features:

1.       “Version 1 Problems”: these are the things developers hit the first time they try to add extensibility to their applications

a.       Loading/Unloading

b.      Sandboxing

c.       Isolation

d.      Lifetime Management

e.      Discovery

f.        Activation

2.       “Version 2 Problems”: the set of things developers hit when they try to version an extensible app

a.       Backwards compatibility: running V1 add-ins on V2 applications

b.      Forwards compatibility: running V2 add-ins on V1 applications

c.       Isolation changes: moving from AppDomain to Process isolation boundaries

d.      Sharing: taking an add-in built for one application and running it in another

 

Our overall goal is to provide solutions to the V1 problems in a way that developers are set up for success when they start hitting the V2 problems.  We’ll be updating this blog regularly with posts about our APIs, architecture, examples, problems we ran into during development, and we’re looking for your feedback on how we can make the Orcas and future versions of our features better and easier to use.  For now I’ll leave you with a snippet  that shows all the code you need (once the object model is defined) to activate an add-in in a new AppDomain with internet zone permissions:

AddInStore.Update(addinPath);

IList<AddInToken> tokens =

AddInStore.FindAddIns(typeof(AddInType), addinPath);

foreach (AddInToken token in tokens)

{

token.Activate<AddInType>(AddInSecurityLevel.Internet);

}