Migrating a Visual Studio Add-In to 2010 - Part 1

With the release of Visual Studio 2010 looming in the distant future and it's new capabilties now seemed like a good time to discover the impact to TeamReview. It's an open source add-in after all, so why not use it as a case study?

And so it begins. I'll be publishing pieces of this "case study" as I progress through the migration. Because Part-1 is a little lengthy here's a guide.

• New pieces of Visual Studio 2010
• Managed Add-In Framework (MAF)
• Managed Extensibility Framework (MEF)
• Windows Presentation Foundation (WPF)
• MAF and MEF Working Together
• MEF and WPF Working Together
• MEF, MAF and WPF as on big happy family
  

New pieces of Visual Studio 2010

VS 2010 leverages the Managed Add-In Framework (MAF) released in .Net Framework 3.5, the new Managed Extensibility Framework (MEF) scheduled for .Net 4.0, and a re-work of the Visual Studio editor to use Windows Presentation Foundation (WPF), which was released in the .Net 3.0 framework. Unfortunately I haven't used any of these technologies yet, so the migration will be quite the learning experience . It sounds like there is a low-impact migration path for an existing add-in to work in VS 2010 without rewriting everything to use these new pieces. A few people I've talked to say their is a "shim" as part of VS 2010 that allows "most" things to work without change. So that seems like a good first step for TeamReview. However, before we try that let's delve a little deeper into the new pieces.


Managed AddIn Framework (MAF)

From the Add-In Overview

The add-in model consists of a series of segments that make up the add-in pipeline (also known as the communication pipeline), that is responsible for all communication between the add-in and the host. The pipeline is a symmetrical communication model of segments that exchange data between an add-in and its host. Developing these segments between the host and the add-in provides the required layers of abstraction that support versioning and isolation of the add-in.

The following illustration shows the pipeline

The rest of the summary lists the add-in model's capabilities in more detail, here's a short review.

• Independent versioning of hosts and add-ins. Use an older add-in in a newer host and vice versa.
  
• Discovery and Activation of Add-ins. Find an add-in by unique identifier or by the type of add-in.
• Configurable Isolation level of the add-in and host including using the add-in as an external process of the host
• Lifetime Management of the Add-In. Due to the various isolation models that can be used garbage collection of a single process or app domain isn't enough.

It seems clear from the literature that MAF will become the core Add-In framework for all/most Microsoft products with Visual Studio and Office included. This would allow a single add-in to be used in many products, which is difficult currently due to the disperate add-in model designs.

At this point my assumption is that I'll have to write some pieces on the right side of the diagram above and that Microsoft has taken care of defining the contracts. Hopefully I won't have to spend too much time writing framework pieces and Microsoft has even written the add-in side adapter and the add-in view and I just have to write the Add-in.

MAF Resources

• System.Addin Conceptual/How To Documentation
• System.Addin API Reference
• CLR Add-In Team blog
  
• System.Addin Tools and Samples (code from the CLR Add-In Team)
• Managed Add-In Framework (Screencast by Daniel Moth)
  
• Version Resilience in the Managed Add-In Framework (Screencast by Daniel Moth)
• Managed Add-In Framework (Blogpost on Screencasts by Daniel Moth)
• Add-In Performance: What can you expect as you cross an isolation boundary and how to make it better [Jesse Kaplan]

Managed Extensibility Framework (MEF)


From the MEF Home Page

The Managed Extensibility Framework (MEF) is a new library in .NET that enables greater reuse of applications and components. Using MEF, .NET applications can make the shift from being statically compiled to dynamically composed. If you are building extensible applications, extensible frameworks and application extensions, then MEF is for you.

That sounds a lot like a IoC Container to me. However, MEF is not just another IoC container, in fact it's not meant to be an IoC container at all. MEF unlike IoC containers is used to compose an application by dynamically including new bounds of functionality through discovery. Each extension can it-self include more discovery of extensions. IoC containers on the other hand know much about the structure and type of functionality and usually determine the parts via configuration. Often IoC is used to choose between a few known options that provide the same type of functionality, such as a stub for testing or the real thing for implementation. Contrary to IoC designs the composition of a MEF app can take endless permutations, and the set of options is not known by the application or the developer before hand.

MEF is meant for larger systems such as Visual Studio which can be extended by numerous people around the world to do un-predictable augmentations of that system. This is starkly different from the goal of an IoC design that's usually used by a development team for flexible testing and extension, but only within tight constraints of known needs. So, MEF is not just another general purpose IoC container.


MEF Resources

• MEF home page (CodePlex)
• Introduction to MEF
  
• Scott Gutherie PDC 08 Keynote presentation
• MEF Example (Brad Abrams)
• MEF Contrib (CodePlex)
  
• Mef'n IoC (Shawn Burke's Blog)
• MEF Vs. Unitiy Vs. System.AddIn...Also, Is Microsoft Involved?
  

Windows Presentation Foundation (WPF)

By now most of us have an understanding of what WPF is so we don't need to go into much detail. However for a short recap here's an "official" wording from the Introduction page

Windows Presentation Foundation (WPF) is a next-generation presentation system for building Windows client applications with visually stunning user experiences. With WPF, you can create a wide range of both standalone and browser-hosted applications.

Why are we talking about WPF in this Visual Studio Add-In article? The 2010 shell and editor is written in WPF. If you want to extend it you're best bet is with WPF.


WPF Resources

• Introduction to Windows Presentation Foundation
  
• Getting Started with WPF
• WPF Fundamentals
• Visual Studio Gets a New WPF Interface
  
• Writing Visual Studio 2010 Shell in WPF Reflects Confidence
• Scott Gutherie PDC 08 Keynote presentation

MEF and MAF working together

MEF is a more generic extensibility model with lazy loads of dependencies, the ability to traverse large catalogs of extensions, dependencies-of-dependencies etc. MAF is focused on isolation and versioning of an add-in model where the host and add-in are most often written by different people or companies at different times.

Whether right or wrong, I find it helpful to conceptually bucket the two by thinking of MEF as achieving the intent of the Decorator pattern and MAF as achieving the intent of the Bridge Pattern.

Are they both used by Visual Studio 2010? Yes.

MEF can be used to augment the look and display of the editor for example to change XML comment display in C# files like Scott Guthrie did in his PDC 08 Keynote. MAF would be used for more invasive changes such as adding brand new functionality that you might want to be isolated from the VS process, or that you want to work in both VS and Office products, or so you can have a different versioning timeline from Visual Studio.

Could you use them together? Yeah, for example TeamReview will be included into Visual Studio via MAF, and then I could my define own MEF extensibility points and provide default implementations to the various TeamReview responsibilities to allow others to extend some aspect of TeamReview with MEF.


MEF and WPF Working Together

If like me, you aren't a WPF programmer already this section doesn't matter as much as the previous two. However, if you are - sorry, I'm not - so what I can tell you is that is that MEF takes care of the composing of WPF portions of an app, so Prism/CompositeWPF is no longer the first choice for putting WPF pieces together in Visual Studio 2010. Instead MEF should be your instinctual composing tool.


MEF, MAF, and WPF as one big happy family

In the end an Add-In will be loaded with MAF, compose itself with MEF, potential surface extensibility points with MEF, and create it's UI facilities with WPF. All three new acronym babies working together as part of one big big happy Visual Studio family.

More Resources

• MAF with WPF (Matt's Blog)
• Increase Performance wiht MAF and WPF using LoaderOptimization (Matt's Blog)
• MEF - WPF Quick Start (Bill Krat)
  
• .NET Frameowrks, CLRs, and Visual Studio Add-Ins (Carlos Quintero MVP)
• VSX Team Blog