Introduction
This article demonstrates how to convert a Visual Studio 2005 project to a compatible 2003 format. The motivation behind this article was twofold. First, I wanted to compile in both .NET v1.1 and .NET v2.0 and secondly, I only wanted to maintain one project file, mainly Visual Studio 2005.
There is an open source project named MSBEE from the Microsoft team that works well to compile to .NET 1.1 from a .NET 2.0 project, but it doesn't support building within Visual Studio 2005, you have to go to a command line prompt and run msbuild. You also will not get the same warnings, intellisense, etc. in Visual Studio 2005 as you would with Visual Studio 2003. That's the main reason why the team didn't support building to .NET 1.1 from within the IDE.
A solution that I see a lot of floating around the Internet is to maintain two project files. One for both Visual Studio 2003 and Visual Studio 2005. Although this works, it is cumbersome and difficult to maintain two identical project files when add, removes, etc. are performed on the files in the project. The main reason why I badly wanted MSBEE to work from within the IDE was to avoid having to maintain these two project files.
So along came the Whidbey project converter. Now I only maintain and work from within Visual Studio 2005, and export my changes to the Visual Studio 2003 format, bring up the everett IDE and compile to .NET 1.1 very easily, with debugging and intellisense support. No more maintenance nightmares, and it all works so well, as opposed to a build hack from within Visual Studio 2005. A large portion of this code came from Jeff Key. I couldn't get his original source to work, because he built it to the Visual Studio 2005 beta1 release specifications. I fixed it to work with the latest and greatest, and am sharing it here if it can be of any help to you as well as it was for me.
Background
This article is an extension of Jeff Key's original work. You can download it here.
Vision
Add direct support from within Visual Studio as an AddIn.
Subversion support ties in with SvnRev and makefiles.
Updated 2006-05-30
I've completed an overhaul of the Whidbey project converter, including some bug fixes that came to my attention after I published the article.
I added command line support to allow it to work in a build environment. The motivation behind that feature is better support for continuous build integration. A little story will do this a little justice. I'm Joe, the developer using Visual Studio 2005. I add/remove some files to/from my project and commit the changes to my repository. Cruise Control .NET (ccnet) automatically notices the changes, updates the local working folder and builds the project, and all would seem well in Joe's life and team, but it is not. If Joe has a substantial project, it has to reference a few other assemblies to build correctly. Let's assume Joe builds his projects and copies the resultant *.dlls to a common directory that all his other projects reference, let's say c:\dev\common\assembly\v1.1. And that's great, it works. With that reference comes a hardlink in the Visual Studio 2005 project file to that local directory on Joe's machine, which probably will not be like the one on the ccnet servers. So how do we fix it so everybody is happy and Joe doesn't notice a thing.
First of all, I have to admit that after installing ccnet and taking the time to learn how to transform an existing Visual Studio 2003 project file into a NAnt build file, I fell in love with NAnt. NAnt supports both v1.1, v2.0, cf, etc. but the biggest boon is in the VSConvert.xsl file you use to transform the project. It's possible to change the hardlinked paths to the dependant assemblies. In my case, I change them to an environment variable LIB_11 and LIB_20 and the project builds flawlessly and doesn't change the pre-existing Visual Studio 2003 project file, so Joe's happy with that. But let's be practical about this, who in her/his right mind is going to want to go to the command prompt whenever they change their project contents by one or more files? Not me. That was problem one with grace land, the second was that the VSConvert.xsl I found on the Web was only for Visual Studio 2003 project files. Where's the solution to all of this? WPC to the rescue. Now not only can it transform Visual Studio 2005 projects, it can create Makefiles to trigger re-building nant.build when it's out of date and it can also perform the XSL transform on the Visual Studio 2003 project for you into a nant.build file. And, you can customize the XSL transform to perform the way you want it to in your own build environment. BTW, I have nothing against msbuild, I just believe from experience that NAnt performs better with ccnet.
