Skip to content

Building Add-in Models for your Applications

June 12, 2007

The CLR in .Net 3.5 has an interesting feature called the CLR Add-in Model.  The CLR Add-in Model team has been blogging since January @

In the first post, Jesse Kaplan, a PM for the team says:

There are two classes of problems we92ll 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
  • Loading/Unloading
  • Sandboxing
  • Isolation
  • Lifetime Management
  • Discovery
  • Activation
2. "Version 2 Problems": the set of things developers hit when they try to version an extensible app
  • 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

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:

IList<AddInToken> tokens = AddInStore.FindAddIns(typeof(AddInType), addinPath);
foreach (AddInToken token in tokens)

Would love to understand what WPF customers would like to do with technology like this. Any feedback you could give the clr-addin team would be great.  Beta 1 of VS 2008 (formerly code named "Orcas") ships this feature…


From → WPF

One Comment
  1. Stefan permalink

    I\’m particularly interesting in how to create XAML UI for the addins. One problem that we came along is that not all classes in WPF are serialized and can be passed through application boundaries. Another problem is the ObservableCollection<T> should have it\’s events marked with NonSerialized, because if you have unserializable subscribers (like WPF classes) the communication between AddIn and the app also fails.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: