Using the System.AddIn namespace

.NET .3.5 created a new namespace called System.Addin which allows us to create AddIns for our applications.

What Are AddIns

AddIns (sometimes called Plugins) are seperately compiled components that an application can locate, load and make use of at runtime (dynamically). An application that has been designed to use AddIns can be enhanced (by developing more AddIns) without the need for the orginal application to be modified or recompiled and tested (though the AddIns should be tested). For some time .NET has allows developers to create applications that use AddIns but this more than likely used the System.Reflection namespace, and was probably a fair bit of work. With .NET 3.5 comes a new namespace, namely the System.Addin namespace. The .NET team have created a very flexible framework for building AddIns, this is known as the AddIn Pipeline (System.AddIn.Pipeline). By using the AddIn Pipeline, the neseccary plumbing is already in place to allow the AddIn model to work. So thats a good thing. The down side to this is that you must implement at least 7 different components to implement the most basic AddIn model. The next section will discuss the AddIn pipeline concept (though it will not discuss the System.AddIn.Pipeline namespace) and shall discuss what happens in each of the 7 (minimum) components that are required in order to correctly setup a AddIn model enabled application

The AddIn Pipeline

The heart of the Addin model is the pipeline. The pipeline is a chain of components that allows the application to communicate with the AddIn. At one end of the pipeline is the Host Application and at the other end is the AddIn, and in between are 5 other components that facilitate the AddIn operation and interaction. Consider the following Diagram At the center of this figure is the Contract (implements System.AddIn.Contract.IContract), which includes one or more interfaces that define how the host application and the AddIns can interact. The Contract can also include serializable types that are planned to between the host application and the AddIn. Microsoft designed the AddIn model with extensibility in mind, as such both the host application and the actual AddIn dont actually use the Contract directly, rather they use their own respective versions of the Contract, called Views. The host application uses the host view, while the AddIn uses the AddIn view. The views normally contain an abstract class that reflect the interfaces in Contract interface (though the view dont inherit from the Contract or implement the System.AddIn.Contract.IContract interface). If this perks your interest I have written a full article complete with a demo project which is available over at codeproject. Or if you just want the demo project without reading the article you can simply use this link demo project.zip

Advertisements

13 thoughts on “Using the System.AddIn namespace

  1. Richard says:

    s/neseccary/necessary/

    Other than that, good article, as usual. Thanks!

  2. sacha says:

    s/neseccary/necessary/

    Not sure what this means, but thanks I think

  3. PierreMF says:

    I have tried to use system.addin with WPF, and I was very disappointed. Since addins are different processes, loading an addin which use WPF is as slow as loading a WPF application. Which means that if the host app needs to load 10 addins that use WPF, it takes almost 1 minute. So I get back using interfaces and reflection 😉 !

  4. sacha says:

    Yeah I think Interface and Reflection is faster probably. I just like to know what my options are, so try and look at all sorts of stuff.

    But I think you are correct.

  5. PierreMF says:

    As far as I know, system.addin is very slow when loading plugins that use WPF. If the plugin does not use WPF, system.addin is quite fast, and has many advantages over interfaces+reflection.

    In my case, the plugins I wrote where referencing WPF components, so they took forever to load. Maybe this is a bit faster now with .NET3.5 SP1.

    Just to let you know my experience… if it may help.

  6. sacha barber says:

    Pierre

    Thannks for your shared wisdom on this, it will help some folk im sure.

    I too noticed they were very slow if the addin used WPF

  7. Greg says:

    Nice article. It helped me a lot. Unfortunately the demo project.zip is not available anymore at codeproject. Is there some other way to get that project?

  8. Michael says:

    I have a following question
    Assume we have application App and 2 addins E1 and E2
    App can load E1 and E2 ( of corse with the directory structure of pipeline as descibed in Your article and MSDN)
    Is possible that E1 will be host for E2 ( and possible other addins ) ?

    Thanks

  9. sacha says:

    As far as I know what you sare proposing I don’t think its possible. TO be honest with you, I found the whole AddIn namespace to be such an overkill that, I do not use it.I either use some reflection or would use MEf these days I think.

  10. Nguyá»…n Trung DÅ©ng says:

    Thanks for the lesson Mr. Barber, Today is March 2009 and I have made an Addin solution based on your lesson. My HostApplication is a main MDIParent which contains all MDIChild (addin), and I have a proplem here:

    [Code]
    Type ‘System.Windows.Forms.MdiClient+ControlCollection’ in assembly ‘System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089’ is not marked as serializable.
    [/Code]

    if I pass this line:

    [Code]
    (Form)child.MdiParent = this; //”this” mean the main MDIParent.
    [/Code]

    My app will run softly without an exeption, but that is not what I want to do with my app 😦 .

    I know that you will not have time, but can you suggest me something, please. Thank you so much!

    PS: I am a Vietnamese student, in my comment, maybe there is some inexactly words, please feel compasion to me 🙂 .

  11. sacha says:

    Nguyen

    Im glad my example helped you out, I just do not have time to help you on this.Sorry.

  12. Natanale says:

    Hi Sacha,

    I successfully made an addin based application using the System.AddIn namespace. But now am faced with a problem, I need to use transparency on the host window to be able to use some custom theming. With the themes enabled, the addins does render on the host window. But without the themes the addins work perfectly well. I am using all WPF usercontrols for the addins. If you could shed light on this matter. Thanks very much!

  13. AKRamkumar says:

    Sorry for the late post, however i have a question.
    Suppose I need to use plugins in WPF, how would i load all in a different appdomain?
    Also, would performance improve if i use threading?

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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: