CruiseControl.NET & VS2005
I've just spent the last 2 days getting my team to migrate our solution from ASP.NET 1.1 to ASP.NET 2.0 most of which was spent cleaning up compiler errors and making changes to get rid of warnings, etc.
This went suprisingly smoothly considering the main solution has over 20 projects in it, and that there are some very ugly internal workarounds for some ASP.NET 1.1 limitations.
Not wanting to do things by halves, at the same time we migrated our backend database to SQL Server 2005. This was simplicity itself - just backup the database and restore it on the new server. How much easier could it get?
So now, we have a solution that compiles, runs and behaves as expected on all the developers machines and we're all looking pretty good.
All the code gets checked into Subversion (our source code repository) and then I remember that I haven't updated our build server. I'd forgotten to check for any "gotchas" on that one when planning the upgrade and it turns out there was one.
We use CruiseControl.NET (cc.net) as a Continuous Integration Server (as per agile methodologies) and this works beautifully. We've configured it to use NAnt to manage the actual build process. Now this usually involves the following steps - clean the previous build, get the latest code from subversion, set version numbers in the assemblyinfo files according to the subversion change set number, do the compile, run the tests and copy the compiled results into a directory for potential release.
The problem is that the NAnt script uses the solution task to compile the code, but under Visual Studio 2005 the solution is now a completely different format and there are no NAnt tasks for managing the build of a .NET 2.0 solution file. It turns out that the only way to do it (apart from building the solution one compile at a time) is to use MSBuild to do the compile.
I didn't want to have to rewrite my NAnt script as an MSBuild script - far too much work, so what I did was to take the compile step, and call MSBuild using an exec task as follows:
<exec program="c:\winnt\microsoft.net\framework\v2.0.50727\msbuild.exe"
commandline='MySolution.sln /p:Configuration=Release
/logger:ThoughtWorks.CruiseControl.MsBuild.XmlLogger,
..\ThoughtWorks.CruiseControl.MSBuild.dll
/noconsolelogger /nologo /noautorsp'
output="_msbuild.xml"
failonerror="true"/>
This worked OK, except that the solution contained a project for SQL 2000 reporting services reports, and this can't be built using MSBuild. I simply removed that project from the main solution, and left it as a VS2003 solution that could be built separately.
The only other thing to note is the XMLLogger is used. This was obtained from the CruiseControl site so that the results of the build could be viewed in the web browser (the workplace) with the nice colourisation of errors, warnings, etc.
A bit of a pain in the neck to figure out what needed to change, but it works now and works well. All the other parts of the build process remain as they were, controlled by NAnt and in the end it's quite a small change.
This went suprisingly smoothly considering the main solution has over 20 projects in it, and that there are some very ugly internal workarounds for some ASP.NET 1.1 limitations.
Not wanting to do things by halves, at the same time we migrated our backend database to SQL Server 2005. This was simplicity itself - just backup the database and restore it on the new server. How much easier could it get?
So now, we have a solution that compiles, runs and behaves as expected on all the developers machines and we're all looking pretty good.
All the code gets checked into Subversion (our source code repository) and then I remember that I haven't updated our build server. I'd forgotten to check for any "gotchas" on that one when planning the upgrade and it turns out there was one.
We use CruiseControl.NET (cc.net) as a Continuous Integration Server (as per agile methodologies) and this works beautifully. We've configured it to use NAnt to manage the actual build process. Now this usually involves the following steps - clean the previous build, get the latest code from subversion, set version numbers in the assemblyinfo files according to the subversion change set number, do the compile, run the tests and copy the compiled results into a directory for potential release.
The problem is that the NAnt script uses the solution task to compile the code, but under Visual Studio 2005 the solution is now a completely different format and there are no NAnt tasks for managing the build of a .NET 2.0 solution file. It turns out that the only way to do it (apart from building the solution one compile at a time) is to use MSBuild to do the compile.
I didn't want to have to rewrite my NAnt script as an MSBuild script - far too much work, so what I did was to take the compile step, and call MSBuild using an exec task as follows:
<exec program="c:\winnt\microsoft.net\framework\v2.0.50727\msbuild.exe"
commandline='MySolution.sln /p:Configuration=Release
/logger:ThoughtWorks.CruiseControl.MsBuild.XmlLogger,
..\ThoughtWorks.CruiseControl.MSBuild.dll
/noconsolelogger /nologo /noautorsp'
output="_msbuild.xml"
failonerror="true"/>
This worked OK, except that the solution contained a project for SQL 2000 reporting services reports, and this can't be built using MSBuild. I simply removed that project from the main solution, and left it as a VS2003 solution that could be built separately.
The only other thing to note is the XMLLogger is used. This was obtained from the CruiseControl site so that the results of the build could be viewed in the web browser (the workplace) with the nice colourisation of errors, warnings, etc.
A bit of a pain in the neck to figure out what needed to change, but it works now and works well. All the other parts of the build process remain as they were, controlled by NAnt and in the end it's quite a small change.