Share via

Welcome to the CLR Add-In Team Blog [Jesse Kaplan]

  • Article

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);

}

Comments

  • Anonymous
    January 12, 2007
    Why does AddInStore.FindAddIns take a Type parameter? Would it not be better to make the method generic?
  • Anonymous
    January 17, 2007
    Version 2 problem --Sharing: taking an add-in built for one application and running it in anotherIs this addressed in the Orcas CTP?
  • Anonymous
    January 19, 2007
    Regarding AddInStore.FindAddIns taking a type parameter rather than making the method generic: we discussed this internally with the design guidelines guys and they recomended going with a type as a parameter.The justification is that if you're using the type information as data (in our case telling the AddInStore what type of add-in you want) you should pass it in as a parameter rather than make the method generic. They only recomended going with a generic method if it actually contributed to type saftey and could help you find more bugs at compile time.Making it generic also would have made it much harder for you to treat the type as data when you don't know at compile time what type of add-in you want.
  • Anonymous
    January 19, 2007
    The current Orcas CTP has everything you need to take an add-in built for one application and running it in another (assuming both applications use our add-in model).We'll have some more information about how this works shortly when we start with a series of posts about our architecture.
  • Anonymous
    January 30, 2007
    Awesome... way to go guys, this is exactly what the BCL team should be working on!KudosPS. I'd still like to see some "standard" framework interfaces for things like Internet Mail (IMimeMessage, etc) that 3rd party vendors should implement.  
  • Anonymous
    November 10, 2007
    Tenuate, http://buytenuate.blogspot.com