By Popular Demand [Jack Gudenkauf]

We just released VS 2008 and .Net 3.5 Beta 2 (code name “Orcas”).

You may download the release here.


What’s new?


1.       UI extensibility

By far the most requested feature has been UI extensibility built upon the Add-In model.

We are very happy to announce that we have delivered a solution!

We have added a Native Handle Contract (in System.AddIn.Contract) upon which, the WPF and CLR Add-In teams have built an implementation for enabling an application to Host WPF Add-In’s!

We will be posting more on the subject including a sample(s) showing isolated (i.e., Cross AppDomain) WPF Add-In’s.

Special Thanks to the WPF team for making this happen!


2.       Direct Connect Optimization

We have provided an optimization to Add-In activation.

For Hosts and Add-in’s having the same view of each other (e.g., in V1) that forgo unloadability and share the same security context (i.e., run in the same AppDomain), you can choose to optimize the Add-In loading behavior (AddInToken.EnableDirectConnect) by not instantiating the Adapters.


3.       Custom Qualification

We now support the ability to add a custom attribute (i.e., QualificationData) to your Add-In and/or Pipeline segments.

There are a number of clever things you could do with this ability.  You could provide your own custom qualification logic for things such as Add-in’s that use this Attribute to inform you they qualify themselves as only running in the default AppDomain, etc…

The attribute data is available via the AddInToken.


4.       Find Add-In

We have added a new method (AddInStore.FindAddIn()) that enables you to find an Add-In given a fully qualified path and type.

Among other uses, this feature allows you to forgo the demand for an Add-In Attribute used for Discovery.

This feature also supports scenarios where you may not know the Add-In location until Run Time (e.g., Add-In’s deployed via Click-Once).


5.       Passing and Re-Adapting Add-In’s (ContractAdapter)

One of the many benefits of the Adapter model is the ability to Re-Adapt.  Sharing Add-In’s without the demand  to Discover and instantiate a new instance is a powerful capability.

We provide facilities to pass the Add-in around and let each consumer of it choose its own view and let the system find the appropriate adapter between the activated add-in and the requested view.


6.       Add-in Activation Security enum

We have added a new enum value for activating the Add-in using the Hosts Security level (i.e., AddInSecurityLevel.Host).


7.       View Hierarchies

We now support a hierarchy of view types and the ability to attribute them for discovery.


We will be posting more on these features in the coming months.  Stay tuned.

Comments (14)

  1. VS 2008 and .Net 3.5 Beta 2 (code name "Orcas") is now available. Here is the link to download . I am

  2. Ian Duncanson says:


    Does the UI Extensibility mechanism also extend to Cross-Process isolation, or is it restricted to Cross-AppDomain?



  3. Kevin says:

    This new AddIn model is the best thing since sliced bread. However, what if a developer wants to completely break the rules the model has specified? Are there any compile/runtime restraints?

    For example, we must do a major software integration between two applications. We would love to use the AddIn model, but I have read the rules that developers should follow when using this model, and unfortunately our requirements force us into breaking those rules. We will have a semi-tight integration between these two applications, and that is fine we accept the consequences, but what are the limits of the AddIn model you have designed?

    Will it allow forms to be passed around?

    Will it allow non-serializable classes to be passed around?

    Will it allow any object to be passed around?

    If these are allowed (if the addin is in the same appdomain as the host), what are the consequences? Is the only downside is loss of independent versioning? If so that is good to know. At least the AddIn model will save us a lot of work of managing addins.

    Remember, there will be many consumers of your framework that do not use it as intended, but you already knew that 🙂

    PS: I tried passing a form from an addin to the host (even from a different process) and it worked, the form was displayed. I was very surprised that worked. Is doing such a thing safe to do? (Safe as in will not crash the application provided no .NET rules are broken)

  4. Cross Process WPF is currently unsupported in Beta2.  We are looking into it.

    Kevin, aside from versioning issues you lose unloadability unless you load in a seperate AppDomain.

    We do not enforce contract constraints in the Run Time.  So you can "violate" the guidance.

    As you mention, you can use the initial discovery and activation and forgo some of the constraints in your OM.  Keep in mind that you will be leaking types however.

    We would love to hear from others about the value of forms extensibility.

    • JackG
  5. Kevin says:


    Thanks for the information. Here is some feedback: image an Office 2007 application like Word such that an AddIn adds an entire new tab and replaces (or hides) Word’s canvas with the AddIn’s when the tab is selected. Like an application inside an application.

    For us,

    Unloadability is not required.

    Versioning is not required (initially at least until a lot of refactoring is performed)

    Sometimes requirements force people into breaking best practices. It is important for developers and architects to understand the consequences of their design decisions, especially when guidelines are broken.

    I anticipate many consumers of your AddIn model to not use it exactly as it was designed (due to how useful and powerful it is). Perhaps a blog post someday about what happens when people bend/break the rules would be good?



  6. Garry Trinder says:

    Kevin, Thanks for the feedback.

    The primary guidance I give to customers is design for Unloadability, Isolation, Versioning, Sandboxing, etc.. now.

    If you decide you do not need all the functionality or you do not take advantage of something like versioning in v1 then there is no adverse side effects.  

    Arguably, complexity is a side effect but that’s what we get paid to understand.  

    If however, you do not design for these features, it is extremely unlikely that you can add them later (i.e., at least without a breaking change or worse, a loss of business).  

    You can always build on our model and still run in the Hosts default AppDomain and thus the same security context.  Or optimize around clumping like (i.e., Same lifetime and security context) Add-in’s in the same AppDomain.

    If you do not Marshal, you do not incur the performance overhead of the transition.  

    And you can always take advantage of our Direct Connect optimization feature.

    As you point out there may be affordances for not strictly adhering to the model and this is precisely why we don’t enforce strict constraints at run time.  We understand that there are always exceptions to the rule.

    In your example of Office extensibility.  The user decides what Add-in’s may be loaded.  This also implies a need to unload them.  

    If an Add-in’s behavior causes the Host application to not perform, this is a huge problem for the user.

    Imagine a 3rd party spell checker that is loaded automatically and causes the Host Word processor app to crash.  

    If the user (or Host – Office  disables loading an ill behaved Add-in) cannot disable the spell checker or can’t readily recycle the process (i.e., to unload and not reload at start-up) they can’t even use the Word Processor due to an ill behaved Add-in.  

    You can also imagine that a user may not understand that the Add-in is causing the Host app to fail and thus blames the Host provider.  Customer perception causes sales of the application to cease.

    Isolation is a critical component for ensuring the Host is “protected” from the Add-in’s adverse behavior.  And Add-in’s are protected from other ill-behaved Add-in’s.  As an example, do a quick search on Office Add-in’s where people ReleaseCOMObject in a loop (yikes).

    Isolation also enables Add-in’s to run in a different security context than the Host.  

    Regarding versioning.  In your example, imagine a 3rd party offering your tab form feature.  If your customer relies on this feature and you release version two of your host without providing compatibility with the Add-in, then the user will be locked into your version one product release and you will not be able to sell upgrades to your product.

    In the end, software engineering is in support of the business. – JackG

  7. Kevin says:

    Fantastic information… I do not disagree with a single word you said. I follow that advice whenever possible, but you will see in my email to you (from your blog) why I have to break some rules initially.

    Great post, I am sure anyone reading will find it valuable.



  8. Ian Duncanson says:


    Just wondering what mechanism (Load, LoadFrom, other) the System.Addin classes use to load Addins, and what if any "gotchas" there are with that chosen mechanism that we should be aware of.

    Also (I know you may be guarded about a response here), you mentioned that you are looking into out-of-process visual addins in the future – are you looking into this for Orcas, or for a future release (again, realize you may not want to answer this, but thought it was worth a shot).

    And a final question – does the visual WPF addins also permit hosting Winforms via crossbow (interop) in an addin?



  9. Ian, We load assemblies from disk and thus we use LoadFrom internaly. We handle all the gotchas for you.  There are a number of things we have all experienced in rolling our own implementation of an add-in loader, including loader context issues, etc..  It is easy to get this wrong and this is why we delivered a robust loader for Add-in’s.

    I don’t have any more information on OOP UI but watch this blog for any changes on the subject.

    As far as Crossbow is concerned see my recent post/video ( – JackG

  10. zzz says:

    What kind of performance implications there are using full vs direct connect and otherwise?

    In far future, suppose we can have the GC run on another core cleaning the garbage without interrupting program execution and thus give means to write an audio application in C#. Now I could want to make it possible to have users to create managed audio signal processing plugins passing some data back and forth quickly as possible to not add too much latency. Is this kind of thing completely unimaginable for the AddIn model or is there a way to do this type of large buffer passing with close to zero overhead? Or can you share a memory section with the addin without creating a need to give it higher priveleges.

  11. Garry Trinder says:

    DirectConnect only works when there is no isolation boundary between the host and the add-in. You won’t get any of the benifits of isolation but at the same time you don’t pay the cost of crossing the boundary.

    We’ve designed the model with performance in mind and made sure that we didn’t add any measurable overhead to the cost of crossing a given isolation boundary. That said you of course will still have to pay that cost.

    The best way to minimize the performance cost of crossing an AppDomain boundary is to design "chunky" rather than "chatty" interfaces. This is because there is mostly a fixed cost for crossing the boundary regardless of how much data you pass across. We’ve done performance tests and the cost of serializing a 100 MB byte[] across an AppDomain boundary was only about 20% greater than serializing a 1MB one. On our reference machine this came to .48 vs .4 seconds.

    In your case it sounds like you don’t need a terribly chatty interface and that the area of most concern is getting a large amount of sound data from the host to the add-in and back. You should always measure but if you are careful you will probably find that the amount of time the add-in spends processing the sound data will be much greater than the amount of time sending the data to it and returning it back.


  12. Torgeir Fredriksen says:

    Is it possible to use Add-In "UI extensibility" with traditional Winforms application (without WPF/Crossbow)? I am asking because we aim for using the 3.5 framework, but due to lack of 3rd party UI controls we want to stick with Winforms for now.

    • Torgeir
  13. Manny says:


    I’ve been playing around with the Calculator application (the one with the graphing parameters on it). I was interested to see if it was possible to create the AddIns in new processes or if not in a seperate appdomain but with a lower trust level.

    I ran into trouble because I wasn’t actually able to do either. However, after a little bit of playing around I realised I could do load visual addins in a seperate appdomain with lower trust settings providing I switched off the Zune theme on my computer!

    Should I be able to create a visual addin in a different process?

  14. In this post I will be showing sample code (also found on our CodePlex site ) as well as an execution