Saturday, November 29, 2008

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.

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.
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.

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.

1 comment:

Valerie said...

I was so excited to see you posting this series... what happened to the "next post" about MAF, MEF, and WPF? I'm researching for a project and trying to find examples of how to tie the three together nicely...