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

My last post was an introduction into the new construction pieces of Visual Studio 2010 add-ins: Managed Extensibility Framework (MEF), Managed Add-In Framework (MAF), and Windows Presentation Foundation (WPF). As mentioned before the migration path for an add-in from Visual Studio 2008 to 2010 doesn't necessitate a re-write if you don't want to leverage these new pieces; let's put that to a test today with TeamReview.

Software First, let's lay out the bits I'll be using. Luckily I attended PDC 08, so I was given most of them on "The Goods" USB hard-drive. It's all available for download however, here are the links. Visual Studio 2010 & .Net 4 CTP The code from TeamReview prior to me making 2010 changes - Change Set 16102 That's it! Just get the 2010 & .Net 4 CTP up and running, and after that download the code for TeamReview.

Converting the Solution and Project files

1. Startup the 2010 CTP server
2. Login as TFSSetup / 1Setuptfs
3. Accept the licensing terms
   
4. Start Visual Studio 2010
5. Create a copy of the 2008 folder of TeamReview (or your add-in) into a "2010" folder for your conversion to 2010, because we don't want to convert the 2008 source in place.
6. Mark the 2010 folder and it's contents as writable. If your 2008 copy was in source control it was probably read-only on disk, which means so is your 2010 copy. The conversion wizard we're going to run the 2010 copy through needs to be able to update those files, so mark them as writable.
   
7. Open up the 2010 copy in Visual Studio 2010
8. Follow the default settings of the Conversion Wizard
   
   
   
   
9. Once the Conversion Wizard is done, review the Conversion Report. You'll likely see a line similar to the following one in your projects. Visual Studio 2010 has some new facilities for segmenting and managing FxCop Rules into distinct sets. That's most likely what causes this line.
   

   Created rule set file "Z:\Developer\TeamReview\2010\TeamReview\VS 2008 Rules.ruleset" for the "Debug (Any CPU)" configuration.

   
   
   
   
10. Now the moment of truth. Compile it and find that (hopefully) nothing breaks. You may find like I did that some assembly references were broken. This makes sense if your 2010 machine doesn't have those referenced assemblies. For example converting TeamReview resulted in 56 errors.
    

    These errors aren't really the fault of the conversion wizard because those references were to the 2008 version of various Team System assemblies, and really they should be 2010 references now. So, it's time to go hunting for those new references.

    For the most part you can open up your project files in notepad and simply replace the number "9" in the assembly name and hint paths with the number "10" to find the new reference. For example the new version of some Team System assemblies that are in "..../Program Files/Visual Studio 9.0/...." for 2008 are now in "..../Program Files/Visual Studio 10.0/...." in 2010. I had a bit of trouble finding a few assemblies that originated from the Visual Studio 2008 SDK. Low and behold a bare-bones version of the 2010 SDK is in the CTP virtual image at "c:\Users\public\documents\CTPWalkthroughs\Visual Studio\SDK". So, close down Visual Studio and ran the installer with all the default options. After the SDK installation completes, you should be able to find the new version of all the assemblies needed in the GAC.
    

11. Now re-compile and and you may find that you still have 1 error (that may lead to some other missing reference errors).
    

    

    
    If you "find all references" on the Settings class you'll see the two declarations with an error indicator in the "Find References" window.
    

    

    
    By looking at the non-converted 2008 code you can see that the conversion wizard didn't mess this up and in-fact there was a mismatch in the 2008 code that the compiler didn't catch, but does now in 2010. Because this code is only executed on add-in installation, which is typically a hard thing to debug and troubleshoot on many different system configurations let's go with the the more relaxed option and set both to "pulic sealed partial."
12. Try again, and.. Success! It compiles. (this is Change Set 18131) But will it run in 2010? Nope, we haven't changed the installer to put the Add-In in the 2010 location and not the 2008 location. Also, the Add-In's configuration hasn't been changed to identify that it runs in Visual Studio version 10 (2010) and not Visual Studio Version 9 (2008). Let's do those steps next.
    
13. First open the TeamReview.VSNetAddIn.AddIn (or your *.Addin) file and change the references from "9" to "10"
    
    
14. Next, open up Program.cs in the TeamReview.SetupRegistrationAction project, this is the custom code that runs during the install. It knows where to put the Add-in file where Visual Studio can find it. Find the reference to 2008 and change it to 10 - not 2010 - just 10. I'm not sure why this change was made but it caught me off-guard the first time.
    
    
15. Rebuild, and run the MSI or EXE in the bin/debug directory of theTeamReview.Setup project
    
    
    
    
16. Go to the Add-In Manager in the Tools menu. Activate TeamReview, and test it out.
    
    

Completion
That completes a basic conversion of an AddIn from Visual Studio 2008 to 2010 - seemingly working with barely any code change. It needs to be tested more, but so far the migration path seems to be pretty painless. The code changes that were made as part of this post can be found in Change Set 18138.

Now for the fun to begin. The next post will start taking advantage of those new pieces in 2010 - MAF, MEF, and WPF.

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
  

Seattle Alt.Net meeting -December 13

The next meetup for the Seattle Alt.Net group will be held on December 13. Seems like there will be a planning session for an upcoming open-spaces Alt.Net meeting in Seattle.

Where: Microsoft, 320 Westlake Avenue N, Seattle
When: Saturday, Dec. 13th, 10am-5pm


Once you arrive, go up to the third floor, and there will be # posted to call to get in.

Seattle Code Camp Presentation

Today I presented at Seattle Code Camp on Coding Standards and Code Review in Visual Studio Team System 2008. The content was a bit of a re-hash of some stuff I've been doing at work with CI Builds and mofiying FxCop rules and at home with TeamReview. While there were only a few attendees, it was still very cool. If you have the opportunity to volunteer for a local meet-up please go for it and don't think twice.

Here's all the content from my presentation including code samples and a team build file - start with the index.html at the root to guide you through. You can find posts on this blog that covers most of it if you look hard enough, ok.. if you look at all.

I didn't get to how treating XML comment compiler wanings as errors works out, or how to baseline your code base by automating Ghost Doc with TheWolf macro that I wrote - but those code samples are included in the downloadable rar file.

Here was the offiical blurb on my Seattle Code Camp presentation:

How to get better Coding Standards and Code Review from VSTS

There's some good stuff in VSTS for coding standards and code review, but how can you use it, and more importantly how can you make it better? In this session I will share my experience of successfully extending and customizing VSTS simultaneously in the open source community and at the enterprise level to get better code by automating the most important code standards and creating more valuable code reviews. Experience, an adoption/implementation plan, and code will be shared.