Visual Studio .NET 2008 (codename Orcas) is just around the corner. With the release of Beta2 a few weeks ago I decided to update some of our work to use VS.NET 2008 Beta 2 instead of VS.NET 2005.

VS.NET 2008 Beta 2 introduces a host of productivity improvements for developers. Many of these are documented on Scott Guthrie's blog entry here. Of particular interest to me is the multi-targeting feature introduced in Orcas. With previous versions of VS.NET each version was tied to a particular release of the .NET Framework.

So, you have:

VS.NET 2002 can only build .NET 1.0.
VS.NET 2003 can only build .NET 1.1.
VS.NET 2005 can only build .NET 2.0.

Orcas allows the following permutations:

VS.NET 2008 can build .NET 2.0 or .NET 3.0 or .NET 3.5.

There's a great blog post by Soma here if you want to learn more about the differences between some of the more recent versions of the .NET Framework including an explanation of 'red' bits and 'green' bits.

Multi-targeting is important to me because our customers currently use VS.NET 2005 and may well continue to do so for some time after VS.NET 2008 RTMs. Yet I'd like our development team to get the most out of the cool new features in Orcas without having to wait for all of our customers to upgrade. Multi-targeting allows us to do this by using VS.NET 2008 internally but shipping VS.NET 2005 code.

However, there are a few issues to be weary of and I'll describe these below.

When you open a VS.NET 2005 .sln file in VS.NET 2008 Beta 2 the Visual Studio Conversion Wizard steps in to convert files as required. The good news is that the .csproj file formats have not changed. However the .sln, .vsmdi amd .testrunconfig file formats have all changed.

If the conversion wizard runs fine, the resulting solution should compile and run in VS.NET 2008 Beta 2 quite happily. For our project we need to ship the source code as well as binaries so the upgraded projects have to also continue working in VS.NET 2005 and this is where I found problems.

Because we must maintain compatibility between the two VS.NET versions, and we have incompatible file formats (.sln, .vsmdi & .testrunconfig) we maintain multiple copies of the files that have changed format. This means that under source control we have:

Main.sln AND MainVS9.sln
Main.vsmdi AND MainVS9.vsmdi
LocalWithCoverage.testrunconfig AND LocalWithCoverageVS9.testrunconfig

Maintaining parallel copies of these files isn't great but due to our requirement to support both formats and lack of time to develop an automated build based solution this is what we have at present.

Conversion problems

This issue is to do with the .csproj files for Web Application Projects which are format compatible between VS.NET 2005 and VS.NET 2008 Beta 2. If I open my original unconverted Main.sln in VS.NET 2005 it references the converted, but compatible, .CSProj files contained in my solution. Within any Web Application Projects the conversion changes the following line (amongst other things)

Before conversion:

  <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v8.0\WebApplications\Microsoft.WebApplication.targets" />

After conversion:

  <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" />

If you try this on a machine without VS.NET 2008 Beta 2 installed the project will fail to load because it cannot find the v9.0 path being referred to. The solution is to alter the converted line and replace it (using Notepad) with:

<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v8.0\WebApplications\Microsoft.WebApplication.targets" Condition=" '$(Solutions.VSVersion)' == '8.0'" />

<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" Condition=" '$(Solutions.VSVersion)' == '9.0'" />

This way the correct version of the Web Application Projects targets will be loaded depending on the version of VS.NET you are using.