Converting VS2005 solutions to VS2008 Beta 2 (Orcas)

Published 31 August 07 01:26 PM | tblack 

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.

Filed under: ,

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# David Williams said on September 27, 2007 5:53 PM:

It appears this solution causes the Build to not populate the _PublishedWebSites folder under the Build Directory.  We used this directory previously to manually copy the files to the target server.

<Copy SourceFiles="@(FilesToCopy)" DestinationFiles="@(FilesToCopy ->'\\server\integration\webapp\%(RecursiveDir)%(Filename)%(Extension)')"

ContinueOnError="true" />

It appears the _PublishedWebsites directory is no longer populated.  We are getting the following error:

Could not find a part of the path 'c:\build\{Workspace}\{BuildType}\Binaries\Debug\_PublishedWebsites\adminweb\web.config

# David Williams said on September 27, 2007 6:07 PM:

I also tried using the DropBuild folder like below, however the _PublishedWebsites directory is never populated, and hence the source code (aspx, config files etc) are never copied to the drop location.  

<SkipDropBuild>false</SkipDropBuild>

# tblack said on September 28, 2007 8:04 AM:

Yep, I see this too. I'm hoping that this will be fixed for RTM.

# David Williams said on October 2, 2007 9:45 AM:

As a workaround, would there be a way to modify the project file in the .vbproj after the latest files have been retrieved, but before compiling starts?  I am thinking about creating a target that uses xml transformation to change the 'Import Project...' property?  I have used XML modification to modify the web.config files after the .sln is build (Target 'AfterDropBuild'), but not to change (the .vbproj) file before the compile.  Is this possible?

# tblack said on October 3, 2007 12:26 PM:

Sadly I've moved onto another project recently so don't have time to investigate this fully. If you're looking for a workaround I'd be inclined to look at the functionality contained in:

"$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets"

and see if you can factor any of that out into your own pre-build event. I think that would be preferable to further modifying the .proj files.

# Kevin Zink said on January 26, 2008 7:00 PM:

Hey guys, I had this same problem where the _PublishedWebsites directory was not showing up in your deploy location. I'm actually using full-on VS2008, too, so it wasn't fixed.

Rather than adding an additional <import> into my project's .csproj file, I left the v9.0 import (I did not add a second import for the v8.0 directory), created the v9.0 directory on my build server, and then copied the v8.0 targets file into the newly created v9.0 directory.

This might help solve your problems. Here's a blog post that goes into more detail: http://zinknation.net/Using+Visual+Studio+2008+With+Team+Foundation+2005+Build+Server.aspx

# Colin Nash said on June 10, 2008 10:07 AM:

I have just been doing this on our servers. The problems you guys are getting seem to be due to the

'$(Solutions.VSVersion)' == '8.0' not evaluating properly. From what i've seen this is because Solutions.VSVersion in VS 2005 evaluates to nothing.

Change the condition to '$(Solutions.VSVersion)' != '9.0' and it works fine.

Leave a Comment

(required) 
(optional)
(required) 
Page view tracker