text: Managed AddIn Framework (System.AddIn) with WPF not fully explain what the various MAF pipeline projects are used for (or the pipeline itself for that matter). It would be in your best interest to watch this excellent screencast from Daniel Roth first.
  What is it?
  - System.AddIn
  - System.AddIn.Contract
  MAF gives your application the following benefits (at the expense of extra complexity and a steeper learning curve)
  - Discovery – Find addins at runtime
  - Activation – Load an addin at runtime
  - Versioning - Backwards/forward compatibility
  - Isolation – Load addins into separate AppDomains/Processes so they cannot crash they whole app, among other reasons
  - Lifetime Management – MAF will handle addin lifetimes and memory/AppDomain management
  - Sandboxing – Load addins with specific permission sets like “Internet”
  - Unloading – Unload an addin without worrying about tedious AppDomain management
  Our goal.
  Step 1 – Define Contact Interface and utilize Pipeline Builder.
  - Prepare the directory structure for your MAF application by creating a parent folder in your Visual Studio 2008\Projects folder (or wherever you choose). I named my folder “CouchPotato”
  - Next, create a new Class Library project for your AddIn contact, I chose CouchPotato.AddIn.Contract. Create this project inside your parent folder from Step 1.
  - Add reference to System.AddIn and System.AddIn.Contract
  - Hopefully you have installed Pipeline Builder by now, so you should add reference to “C:\Program Files\Microsoft\Visual Studio Pipeline Builder\PipelineHints.dll”
  - This assembly does not need to be deployed with your application. It is only used by the Pipeline Builder during debugging
  - Create your contract interface, I chose the following
  [AddInContract] public interface ICouchPotatoAddInContract : IContract { string Name { get; } string Description { get; } void Initialize(); INativeHandleContract HomeScreen { get; } }
  - For now, don’t worry about INativeHandleContract. This is an interface that the MAF team added to support much better UI passing between isolation boundaries (AppDomains). This interface allows an AddIn to very easily pass direct UI elements to the host application, which is very important for my application.
  - Notice that MAF requires two rules for your AddIn Contracts: first you must derive from the IContact interface from System.AddIn.Contract assembly, as well as add the [AddInContract] attribute also from the same assembly.
  - Next, I chose to specify some naming ‘hints’ to the Pipeline builder. These hints tell the Pipeline Builder utility what to name the 4 assemblies that it will be generating for me. Click here to view all available Pipeline Hints
  ")]
  - We are almost done, but before we build this project we need to change to output path from the default “/bin/Debug” to “../output/Contracts”. For further explanation on this please see the excellent screencast by Daniel Moth.
  - Ok we are ready to build, go ahead and build your project.
  - This step is important because the Pipeline builder does not examine your source code to generate the dependent assemblies, only the compiled code via reflection.
  - Launch the Pipeline Builder from the Tools menu. Default settings should be fine if you have been following along. Pressing OK should generate 4 new projects to your solution, as seen above.
  - Note: I believe this is a bug I ran into with the Pipeline Builder CTP, but in my case I was forced to rename the generated Assembly Name/Default Namespace after the first generation as seen below. Take a look at your projects and verify these settings. Once you change them the first time you will not have to do it again, even if you use Pipeline builder again (and you will).
  Step 2 – Create our Host WPF Application
  Now that our AddIn Pipeline is complete let’s create the host application.
  Open a new instance of Visual Studio and create a new WPF Project, create it inside the same parent folder that we used for our Contracts project.
  - Add reference to System.AddIn
  - Add reference to your HostView assembly that can be found by browsing to “../output/CouchPotato.AddIn.HostView.dll”
  - Important: Make sure you set CopyLocal=false for your HostView assembly
  - Finally, change your build output path to the root output directory
  - I have created a very simple WPF Window with a TabControl. As you can see I am taking advantage of the ContentPresenter control to handle rending of the AddIn control for me. This is a great trick
  >
  - That is the last of our host configuration. Last thing we need to do is Update our AddInStore and load some AddIns (unfortunately, we don’t have any yet, please see Step 3 :); }
  Step 3 – Create our first AddIn
  For this last step we are going to create a fake PhotoGallery AddIn.
  - Open a new instance of Visual Studio and create a new Class Library project, create it inside the same parent folder that we used for our Contracts project.
  - Add reference System.AddIn
  - If this is a WPF Addin, add reference PresentationFramework for FrameworkElement
  - Add reference to your AddInView assembly that can be found by browsing to “../output/AddInViews/AddInView.dll”
  - Important: Make sure you set CopyLocal=false for your AddInView assembly
  Set the AddIn output to a specific directory within the output/AddIns folder, for example:
  - ..\output\AddIns\PhotoGalleryAddIn
  - Now that configuration is complete let’s create our UserControl that will represent the UI for the AddIn. Simply right-click on the project and Add New Item, select WPF User Control, add any UI that you choose.
  <UserControl x: <Grid> <TextBlock Text="Happy Photos!" /> </Grid> </UserControl>
  Lastly, create a the WeatherAddIn.cs file
  - Implement the ICouchPotatoAddIn interface
  - Add the [AddIn] attribute to describe the AddIn.
  - As you can see below, the Pipeline Builder has turned the INativeHandleContract interface into a FrameworkElement for us! This is very handy, as it will allow seamless calls from UI elements across AppDomains without us knowing anything about it! All we have to do is return any FrameworkElement to satisfy the contract, in this case, a WPF UserControl does in fact derive from FrameworkElement, as does just about anything in the WPF visual namespace.
  ; } } }
  Run it!.
  