Graeme Hill on .NET development

Cruise Control is meant to help manage your builds based on the code in source control, and since ccnet config files are basically code, it only makes sense that they should be a part of this process. Basically, there are two problems I wanted to solve:

• If I change ccnet.config and introduce an error, I want to be able to roll back to a previous version in SVN.
• When multiple developers are working on ccnet.config, they should not be fighting over the same file on the CI server. Instead, each developer should be editing a file in their working copy and then merging changes into the repository.

Both of these issues are actually very easy to solve. Using SVN, you can create a repository with only one file: ccnet.config. Then add this project to both the ccnet.config in SVN and the one actually used by Cruise Control (probably in C:\Program Files\CruiseControl.NET or something like that):

  <project name="ccnet config">
    <sourcecontrol type="svn">
      <executable>C:\path\to\svn\on\CI\server\svn.exe</executable>
      <workingDirectory>C:\CI</workingDirectory>
      <trunkUrl>http://localhost/svn/myrepo/trunk</trunkUrl>
      <autoGetSource>true</autoGetSource>
      <username>SVN_USERNAME</username>
      <password>SVN_PASSWORD</password>
    </sourcecontrol>
    <tasks>
      <exec>
        <executable>C:\Windows\System32\xcopy.exe</executable>
        <buildArgs>/Y C:\CI\ccnet-config\ccnet.config "C:\Program Files\CruiseControl.NET\server"</buildArgs>
      </exec>
    </tasks>
  </project>

All this does is check out the config file and then copy it to the location used by Cruise Control. Remember to edit all the paths above with the actual ones for your setup.

That’s all you need to do! The config file is now versioned and Cruise Control is automatically updating itself every time you commit.

I held out for a while, but I have officially become a Git convert. Now that TortoiseGit has reached version 1.0 I can’t think of a single way in which SVN is better that Git. There are a lot of advantages, but by far my favorite is the distinction between “commit” and “push”. In any version control system it is good to commit as often as possible so that you have better version history, but in SVN every commit gets pushed to the server. This means that if you want to commit, but you are not ready to give the code to other developers (ie: the code does not belong on the trunk of the master copy) then you have to make a branch. In SVN it can be a major pain to do everything in banches because of poor (not to mention slow) merging functionality. With Git you can commit as many times as you want, then when your code is ready for the trunk, you can push it to the master server. Much more civilized! If you haven’t tried Git yet then you should. You will be impressed.

Here’s an article on learning Git for SVN users: http://git.or.cz/course/svn.html

Here are some tips for using SVN with a Visual Studio project:

Choosing a client

There are quite a few SVN clients out there. If you like to have one built in to the IDE, then there’s Ankh SVN and Visual SVN. I have used Ankh but found it to be a little buggy (those issues may have been resolved by now) and I have never used Visual SVN because it costs money. I prefer not to have my SVN client built into the IDE though because I often need to do SVN operations outside of Visual Studio anyways. It can also complicate the process a little bit. For example, if you just want to commit your solution file with Ankh, you would probably right click on the solution and choose commit, but this actually commits everything in the solution, not just the solution file. If you use an external client like Tortoise SVN or Rapid SVN then you will get full control over your SVN activity. Both clients are good. Tortoise is a windows explorer extension, while Rapid is a standalone app. Personally, I use Tortoise, but some people don’t like anything that messes with the explorer.

What not to commit

Most of the time you do not want to commit your binary files, just the source, so you should tell SVN to ignore the bin and obj folders in each project. Every solution also has a .suo file that stores the state of the IDE (eg: the files you have open). So for example, if user X commits his .suo file and user Y does an update, then when user Y reloads the project it will open the windows user X was viewing, not the ones user Y was viewing. This isn’t normally the desired behaviour, so you should also ignore the .suo file (it’s in the same directory as the .sln file).

External libraries

When your solution and project files are being versioned, you don’t want to have references to DLLs on your hard drive with absolute paths. Instead, it is ideal to include a folder called lib in your project and put all your DLLs in there so that the entire folder can be included in SVN, ensuring that the references will work for everyone.

Updating from an external client

If you use an external SVN client like Tortoise or Rapid then you do not need to close Visual Studio to do an update, but for the love of god, make sure to save your files before you update. If any of the files or projects you have opened are changed by the update you will be asked whether to reload them. Say yes (if you have files with unsaved changes those changes will get overwritten, that’s why you need to save before updating). This can take a few seconds if any large projects need to be reloaded. After it’s done you might see a bunch of compile errors. Usually they will disappear with a simple compile, but sometimes false errors will still be displayed until you do a full rebuild of the solution. If the compile errors persist then it is likely a legitimate error and you need to take to whoever committed last.

Omitting certain projects in a solution

If you have a project in your solution that you do not want to commit (eg: a test project) then it is not enough to simply ignore the files for that project. If you just ignore the files and commit, then when another user gets your update they will receive an error saying that the project you omitted cannot be found. This is because the .sln xml file keeps track of the projects in your solution, so now it contains a reference to a project with no files. To prevent this you need to right click on the project in Visual Studio and choose “Remove” before committing. This will just remove the project from the solution, it won’t actually delete any files. Note: removing the project changes the .sln file, but it does not automatically save those changes. In order to save the .sln file you need to recompile the solution or do a “save all” (ctrl+shift+S).