If you’re an early Visual Studio adopter like me you’ve probably gotten used to running into a similar problem every few years: upgrading your code. Although VS usually handles the job of converting files to work in the newer version, the big problem has usually been trying to go back to the old version. If you’re the only one working with the code that might not matter, but if you work on a team that has a mix of, for example, VS 2008 and VS 2010 Beta clients, the conversion process causes problems for one or the other.

Finally in VS 11 this problem is being addressed. The ultimate goal is to be able to open a VS 2010 solution in VS 11 with minimal conversion and applying no breaking changes to the project or solution files that would prevent it from still opening directly in 2010. There will of course be some restrictions, like not upgrading to .NET 4.5, but in general seems like a pretty reasonable goal.

To see how it’s working so far with the Developer Preview I tried upgrading a few of my own projects, including a 50+ project solution with lots of complications. The good news was that the upgrade process did succeed without preventing VS 2010 from opening the converted solutions that I tried. There were, however, some issues.

• Modeling projects (for UML architecture diagrams) need some conversion to update tooling version numbering and point to a new location for some MSBuild .targets file references used to build the project. This didn’t appear to create any real problems and is probably going to stay the same until the release version.
• The solution file itself was previously one of the biggest stumbling blocks and usually required separate copies be created for each VS version. The upgrade changed some version numbers but otherwise kept most of the content, with some exceptions below.
• Some reordering took place of projects, build configurations, and source control configurations. This didn’t appear to cause any problems in itself, but I also couldn’t figure out why the reordering took place.
• Solution folders did not fare well. Although I started with projects in multiple solution folders, only the projects which required some conversion stayed in the folders. Other projects were all placed in the solution root, leaving the solution folders present, but empty. Here are some before and after shots of a test solution showing the solution folders and the changed files:

• A WPF application project which was using some customized MSBuild to do automatic environment specific config file switching required updating. One part of this was importing of an external .targets file, which seemed to be treated similarly to the conversion done with the modeling project.

<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets" />

Unfortunately some other changes were also applied, including some additions which ended up causing compile errors related to a bad System.Xaml reference:

• The type ‘System.Windows.Markup.IQueryAmbient’ is defined in an assembly that is not referenced. You must add a reference to assembly ‘System.Xaml, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089’.
• The type name ‘IComponentConnector’ could not be found in the namespace ‘System.Windows.Markup’. This type has been forwarded to assembly ‘System.Xaml, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089’ Consider adding a reference to that assembly.

This change only took place when the extra Import was present. It ended up being a pretty easy fix by editing the project file xml. The cause appears to be that part of the conversion is to add <Generator> and <SubType> nodes to every element with an Include attribute ending in “.xaml” but it doesn’t do any checks to see if those nodes are already present or if the parent node is a Reference instead of a file. Here’s the xml to look for:

<Reference Include="System.Xaml">
  <RequiredTargetFramework>4.0</RequiredTargetFramework>
  <Generator>MSBuild:Compile</Generator>
  <SubType>Designer</SubType>
</Reference>

To fix, just remove the Generator and SubType elements. (I reported this on Connect so it should be expected to be fixed before release)

Overall, there’s obviously still some work to do, but given where it already is in the Developer Preview, I’m looking forward to being able to smoothly move back and forth between versions without all the manual file duplication and hand editing that used to be required.