MSDN Magazine Add-In Articles [Jack Gudenkauf]

The first of two articles we wrote for MSDN magazine was published online today (and available in newstands now):

 This article introduces you to our APIs and walks through a sample application hosting add-ins. Next month we’ll focus on V2 of the same application and go through the details of our architecture and how it solves the versioning problems.

Comments (12)

  1. Monkeyget says:


    I heard about the add-in feature through the BCL blog. Since i have created or worked on a few applications which use plugins, it picked my interest.  I have a few questions.

    -Will it work on the compact framework? I ask that because i worked on a mobile application which used a plugin system at it’s core. It’s the kind of feature that would (have) be(een) nice for that application.

    -Can you choose were the plugin is located. For example is it possible to load a plugin from a shared folder somewhere on the network?

    What about retrieving plugins from a database. You could add functionality by adding data to the database(which is administratively easy) instead of having to roll a new version of the application(which is administratively hard). That’s the kind of thing that would be possible in Java by using a custom classloader but I have no idea how it could work in .NET.

    -Why on earth did you choose the name "add-in" instead of plugin (or at least add-on) which is a more standard word.

    live search returns :

    2.563.262 results for add-in

    5.709.748 results for add-on

    16.849.293 results for plugin and 10 other million result for plug-in.

    -Is there a performance cost when using an add-in? (Code execution, call).

    -What about versioning? It’s the kind of things that you don’t think about and bites you back in the a** later.

    How can i define that a plugin works with version 0.4, 0.5 and 0.6 but no other versions. What if I want change the contract between the host and the add-in in a way that’s compatible or incompatible with older version of add-ins?

    Will I have to keep track of the versions myself or will the add-in system somehow help me?

    Can i run add-ins created for different version of the application at the same time?

  2. Garry Trinder says:

    There’s some good questions here, I’ll try to get to all of them:

    “Compact Framework Support”

    Currently we are not shipping as part of the compact framework, but we’re open to considering it in the future. If you can tell us a little more about the CF scenarios you’ve ran into that would have benifited by this system we’d love to here it.

    “Pluggin locations/deployment”

    We’re very flexible as to where the pluggins are located. You can pass in network shares  and relative paths to our API and as long as the current user has read access to those directories we’ll be able to read all installed add-ins at those locations.

    We kept ourselves out of anything fancier than a disk based discovery/activation model because once people move beyond that their requirments diverge radically. Instead, we provide what’s needed to build those systems on top of us. We’ll have more on a future blog post (maybe with some interesting samples) but we’re working with a few internal teams that will be building a database based deployment system as well as some that would like to discover and activate add-ins from the internet.


    We more or less inherited this name from previous groups and in Visual Studio land everyone uses “Add-In” so we’re used to talking about it in those terms.

    Besides, at least this way an internet search for add-in is more likely to be talking about us 😉

    “Performance Costs”

    Again we’ll have more information about performance in future blog posts but the good news here is that the overhead is quite low. Our perf tests show that if you are already using an appdomain boundary to isolate add-ins we add less than 1% to the cost of each cross domain method call.


    One of our primary goals in introducing this feature was to solve all these versioning problems that come back to bite you after you’ve released once and start working on version 2.

    We’ll be talking about versioning and how our model addresses the various problems related to it a lot and our next msdn magazine article will include an overview of our architecture as well as demonstrate how you can keep old add-ins working, and run them side by side with new ones, even as the host and it’s contract changes radically.

    The short answer is that the system manages versioning for you at runtime and that the host code itself will not have to worry about all the different add-in versions (and vice versa) but that you may have to build and deploy cross-version adapters to enable some of the more interesting versioning scenarios.

  3. Michael says:

    Do you plan to get into a technical discussion for those of us who are familiar with things like Pratschner’s book. I kind of want to know what’s going on under the hood.

    It would be great to have something that "just works", but I want to know what’s going on. We’re working on the add-in issue right now. If we like what you’re doing, is there any "go live" license so we can ship a product using the CTP libraries?

  4. Michael says:

    Well, I doubt we’ll have any hope of using stuff you’re working on 🙁 The CTP is the whole Orcas thing, VS and all. It would be nice if you had a separate download of just the Add-In classes and then roll it into the next version of VS, kind of like what the WinFx team did.

    I might get a go-ahead to use a go-live release of just the add-in technology (if it existed), but there’s no way I’ll get the go ahead to use a whole new version of the .Net framework, even if there is a go-live license.

  5. Garry Trinder says:

    We’ll be going into much more technical detail both as to the architecture our model prescribes as well as to details about what goes on underneath the hood. If you have specific topics you’d like to hear about please let us know.

    I’m not familiar with any plans around releasing go-live licenses of the Orcas .Net FX but I may have some good news for your about the Orcas .Net FX. It is going to be released in a very similar manner as the .Net FX 3.0 (WinFX) was. Orcas (3.5) .NetFX will not be a brand new release of the framework but rather a servicing of existing versions with a few additional assemblies.

    It will essentially be:

    .NetFX 2.0 + servicing

    WinFX 3.0 + servicing

    New Assemblies (such as System.AddIn)

    This means that you won’t have to worry about the deployment of the 3.5 FX impacting existing applications as it only includes a servicing of the bits existing apps are built against and won’t bring down a brand new runtime or BCL.

  6. Michael says:

    That’s potentially good news about how it will be delivered, but without knowing any plans or timeframes for go-live licenses, we’re probably still going to have to roll our own due to our product release deadlines 🙁

  7. Garry Trinder says:

    Just to clarify my previous comment:

    The current plan is that the 3.5 NetFX will only be available as a single package that includes the three pieces I described above.

    As far as impact to existing applications is concerned it only includes a service pack to existing bits and so it will be safe to deploy.

    It will still be a full sized redist as it actually includes all of 2.0 and 3.0 (not just the SPs) + the new bits.

  8. Michael says:

    Thanks for the clarification.

    If it’s just a service pack to existing bits, does that mean we would expect the minor version numbers on the 2.0 framework assemblies to change, but they would still be "2.0.x.y"? I would assume that just means bug fixes, but nothing becoming obsolete, etc?

    Just realizing there will be "servicing" could make it a tougher sell internally, as our QA department would have to re-test things against the serviced 2.0 framework.

  9. Michael, We talk about Orcas (i.e., The next VS/CLR release after the current VS 2005/Whidbey) release as Red and Green bits.  

    The Red bits are a servicing release (as you mentioned just non-breaking changes to Whidbey (i.e, VS 2005) CLR v2.0.  The green bits are new features in Orcas (i.e., NetFX 3.5).  The Green bits are were you will find the new AddIn libraries and things like LINQ.

    Checkout an old post of mine on the subject of red bits (

    It is also confusing since we renamed WinFX and bundled the CLR 2.0 with WinFX (  This should all now be as clear as who’s on first, since I don’t know is on third 😉

  10. Gary Depue says:

    Will there be a utility provided to auto-gen cross-version adapters (host adapter-contracts-proxy layer) from my existing application’s OM?

  11. Great question Gary.  We are contemplating a tool that would generate the pipeline from something like a contract, as well as a tool to generate a pipeline from an existing OM.

    • JackG
  12. website:

    Search engine optimization (SEO) is the process of improving the volume and quality of traffic to a web site from search engines via "natural" ("organic" or "algorithmic….