Dashboard > CruiseControl.NET Community > ... > Contributions > Whidbey Project Converter
Whidbey Project Converter Log In View a printable version of the current page.

Added by Andrew Cates , last edited by Andrew Cates on May 30, 2006
Labels: 
(None)

The motivation behind Whidbey Project Converter (WPC) was for better support of the continuous build integration. A little story will do this a little justice. I'm joe developer using VS2005. I add/remove some files to 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 joes life and team, but its not. If joe has a substantial project, it has to reference a few other assemblys to build correctly. Lets assume Joe builds his projects and copies the resultant .dlls to a common directory that all his other projects reference, lets say c:\dev\common\assembly\v1.1. And that's great, it works. With that reference comes a hardlink in the VS2005 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 everybodys 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 VS2003 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. Its 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 VS2003 project file, so Joe's happy with that. But lets be practical about this, who in their 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 VS2003 project files. Where's the solution to all of this? WPC to the rescue. Now not only can it transform vs2005 projects, it can create Makefiles to trigger re-building nant.builds when its out of date and it can also perform the XSL transform on the vs2003 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.

But what happens when Joe checks in the project file, and another developer checks it out? Developers on a shared project should not be using directories outside the common build tree, so that all references can be relative and work for all other developers.

Powered by a free Atlassian Confluence Open Source Project / Non-profit License granted to ThoughtWorks, Inc.. Evaluate Confluence today.
Powered by Atlassian Confluence 2.7.1, the Enterprise Wiki. Bug/feature request - Atlassian news - Contact administrators