I thought this looked like an interesting approach to validating your SQL statements in a continuous integration environment.  Basically you execute the script with the NOEXEC option.

I'm not sure I would actually us it though since I think I would prefer to actually run the scripts and and then do some further processing, however maybe this is a good prebuild step?

I created a modified version of CCTray to be able to right click and deploy the last build to an environment. 

CCTray just silently runs the NSIS installer for the project, but I'm going to change this so that the installer UI will show up - but only show the progress bar.  The workflow is:

1. Make local change.
2. Commit to SVN.
3. CruiseControl.NET automatically kicks off a build.
4. A couple minutes later I can right click in CCTray and deploy to Dev or Test environments.
5. Send out an email to QA.

I did a commit from my home PC tonight where I don't have CCTray installed.  I don't have it installed largely because I'm usually disconnected from work VPN and CCTray will just show up as a gray ball in my systray.

After committing my changes I felt pretty nervous because there were a lot of new files added to the project and I wasn't using VisualSVN which would normally make sure these get committed.  After checking my email and not seeing any commit mails from the SVN server - I got very nervous.  Did my commit go into a black hole?  Is SVN down, did the build server crap out, is email down?  Ah!

I finally figured out Outlook wasn't synchronizing my Checkins mail folder for whatever reason.  In a panic I went and installed CCTray, and found that my commit was just fine and SVN didn't send it into a black hole after all.

I didn't realize that working with a continuous integration server with almost instant feedback is so tightly integrated into everything I do development wise.  What really surprised me was how much I use commit emails.  I didn't like commit emails when I first started the practice (they were a manual affair then), but now that they get auto generated upon commit using CaptainHook and use the SVN commit description, I've grown to really like them.

Now I can sleep soundly knowing that my code is safe.

If you look at all OSS projects out there (the good one's anyway), they don't even check in their AssemblyInfo.cs files, as these are auto generated when you run a build and the version # is just an MSBuild or NAnt property.  CC.NET should track the version number in its local project state file and pass that into the build script, or the version should be deduced from source control meta data.  Here are some typical responses from developers why they like keep version numbers in a text file checked into source control:

1. But what if we need to do a local build which needs to be versioned with something besides 0.0.0.0?  Why on earth would you ever need to do that?  Local dev builds should never be official, thus should never be deployed.  The continuous integration server is the integration point, not your local desktop.
2. But I need to use a specific version because my assembly is strong name signed to a specific version and I want to hot swap a DLL for testing purposes (or something more sinister).  If you really, really want a local versioned build, override the script's version property, but really you should be using a binding redirect in your app.config.
3. What happens if the build server dies and we lose the state file?  That's why you label source control with the version # every build, which you can use to build a new state file on the new CC.NET server.
4. We don't label source control, so now what happens if the autobuild server dies? You do output versioned builds somewhere don't you?  Look at your last build and rebuild your state file.
5. But, but, but...  That's how I've always done it.  Why? Sure its nice to keep everything in source control, but in this case there's no need.  Really you should be using the meta data of your source control system to manage build version increments, not some text file in source control.

While your removing your version.txt from your source control system, consider switching to SVN while your at it. 

I finally figured out why I was having problems specifying sub-folders (other than trunk) in my ccnet.config SVN source control provider trunkUrl element.  After toying around with svn log (which is what CC.NET uses to find changes), I discovered it only worked on some of the folders in our repository.  As it turns out you must specify the folder ensuring you are respecting letter case.

This does not work: svn log http://mysvnserver/svn/gp/trunk/commons

This does work: svn log http://mysvnserver/svn/gp/trunk/Commons

Notice the upper case C on the second line.  I'm sure this is probably documented somewhere in the SVN docs, but I don't remember seeing it.  The other possibility is that Apache is causing the problem.  Perhaps on Monday I'll care enough to look at the docs.

By now most of us have figured out how to create sophisticated build scripts using NAnt, NAnt is the de-facto standard among .NET OSS projects and for good reason.  NAnt is the best build system on the .NET platform.  So with that out of the way, why would I be writing a series on MSBuild? 

Here's the biggest problem with NAnt as I see it, NAnt doesn't work in the de-facto .NET IDE, Visual Studio.  In Java, Ant build scripts work right there in your IDE.  As good as NAnt is, there's still the context switch cost of switching between Visual Studio and the command prompt.  Aw but I have hot keys you say.  OK, but some newbie dev on your team certainly doesn't, and in general most .NET developers are most comfortable within the realms of Visual Studio rather than the command line.  Like it or not, most .NET developers don't want to build through a command line before they can build through Visual Studio.

The other advantage MSBuild has is that csproj files work natively in the build engine.  If the C# project works in Visual Studio, then you know it will work on the command line with MSBuild.  There's no need to maintain two separate build scripts or any other silliness.  I have also found MSBuild to be really good at resolving dependant nested builds.  So without further ado, here's the rundown of posts I hope to hit in this series:

1. The basics, project structure.
2. Configuration file management.
3. Building the database.
4. Unit testing.
5. Code documentation with Doxygen.
6. Preparing your build artifacts for deployment.
7. Integrating with CruiseControl.NET.

Well, I fixed our CC.NET build that builds one of our C++ projects.  The MSBuild script was taking longer than the timeout specified in CC.NET (which was set to 5 minutes), so CC.NET was killing the build before it finished without reporting as to why the build was failing.

After moving the CruiseControl.NET server to a virtual instance of Windows Server 2003, we've been having problems with NDoc hanging.  I've noticed previously that NDoc was apparently leaking memory thus forcing me to reboot the server every night.  I think it may be opportune time to swap out the alpha version of NDoc we've been using up to this point for Sandcastle, Microsoft's (beta) code documentation generator.

The idea was to make the autobuild system hardware independant, which I think we achieved, however I wonder if it was worth the extra effort. I think it will be beneficial in the long run since the build is dependant upon the following apps/tools which are not is source control: .NET 2.0, a local SQL Server 2005 instance, CruiseControl.NET, and Perforce.

So far I'm pretty impressed with Virtual Server, especially the ability to mount ISO images directly to the guest CD drive. I can't believe I haven't used VS before today.

The only strange issue we ran into was a "VMRC Negotiate Authentication" problem. Everytime we tried to reconnect to a instance authentication would fail. Setting the authentication mode from Automatic to NTLM fixed this issue for us.