Subversion and CruiseControl.NET can be invaluable tools in your .NET development process. There are many resources available to help you get started which I’ll try to gather in this post along with some of my personal experiences.

Let me start with the list of recommended software:

• VisualSVN Server is the ultimate Windows version of Subversion including a simple setup and powerful management tools. If you are planning to install a Subversion server on Windows it should be your first choice.
• AnkhSVN is a Subversion Source Control Provider (SCC) for Visual Studio. As long as you’re not using Express editions of Visual Studio, this is the suggested way of working with SVN directly from Visual Studio IDE.
• TortoiseSVN is a Windows shell extension for working with Subversion from within Windows Explorer. When you're not working with Visual Studio solutions this is the best choice for using SVN.
• CruiseControl.NET is a continuous integration server including a web dashboard and CCTray - a system tray client application for monitoring and controlling builds.

If you’re not already familiar with the above mentioned products, you should consult their documentation or search for tutorials. I will rather focus on setting up your development and release process. If you haven’t done so already I suggest you first read the following articles by Ariejan de Vroom:

• How to structure your repository
• How to release software properly
• How to fix bugs properly

I mostly based my configuration on the ideas in these articles. I have projects configured in CC.NET to build all copies of the project: trunk (ProjectName-Trunk), all branches (ProjectName-REL-#.#) and all tags (ProjectName-v#.#.#). To identify individual builds I am using CC.NET’s Assembly Version Labeller together with AssemblyInfo MsBuild Community Task.

Assembly Version Labeller is really simple to configure. You only need to add a short snippet to each project:

<labeller type="assemblyVersionLabeller">
    <major>1</major>
    <minor>0</minor>
    <build>0</build>
</labeller>

I’m using the following versioning policy:

• I start each project with version 1.0.0.
• Once it’s ready for release I make a copy of the trunk in the branches directory, named REL-#.# containing the major and the minor version number. Immediately afterwards I bump the version of the trunk (only minor or major and minor, depending on the nature of the new features planned).
• In the release branch I make the necessary changes before release (e.g. I change the AssemblyProduct name to distinguish between development and release quality builds) and make another copy in the tags directory, named v#.#.# containing the major, minor and build version numbers. Immediately afterwards I increase the build version number in the release branch.
• I make no changes to the copies in the tags directory. All bug fixes go to the release branch. Once I’m ready for a new release I repeat the previous step.

Since I don’t specify the revision number directly, the SVN Revision number gets used automatically. This makes it possible to match each build to the revision of the code in SVN.

To put the generated assembly version in the build I am using the AssemblyInfo MsBuild task. There are two steps involved in doing this.

First you need to move the AssemblyProduct, AssemblyInfo and AssemblyFileVersion attributes from the auto generated AssemblyInfo.cs file into a new file. In my case the AssemblyVersion.cs has the following contents:

using System.Reflection;

[assembly: AssemblyProduct("ProjectName DEV")]
[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]

Next you have to modify your project file (*.csproj) by importing the community tasks and adding a call to the AssemblyInfo MsBuild task:

<Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" />
<Target Name="BeforeBuild">
    <AssemblyInfo Condition="'$(CCNetLabel)' != ''"
        CodeLanguage="CS" 
        OutputFile="Properties\AssemblyVersion.cs" 
        AssemblyProduct="ProjectName TRUNK" 
        AssemblyVersion="$(CCNetLabel)" 
        AssemblyFileVersion="$(CCNetLabel)" />
</Target>

If you have never edited a project file before, you might want to read these first:

• How to: Edit Project Files
• How to: Extend the Visual Studio Build Process

One more thing to note which might not be all that obvious. The Condition in the AssemblyInfo task is met only when building from CC.NET. For builds in Visual Studio the task doesn’t regenerate the AssemblyVersion.cs file therefore the revision number is always 0 and the AssemblyProduct has a DEV suffix as defined in the original file. Also I remove the TRUNK suffix from the AssemblyProduct attribute of the AssemblyInfo task when moving code from trunk to release branches to separate between the two.

Query parameters are a very useful Excel feature allowing parameterization of database queries used to import data in Excel. They are really simple to use as well. On the Definition tab of the Connection Properties dialog there is a Parameters… button at the bottom. It gets enabled as soon as there is a parameter defined in the Command text – you define it by typing in a question mark (?) instead of a value in the WHERE clause of the query, as seen in the image below.

Unfortunately there is a limitation for using this functionality which turns out pretty unintuitive in Excel 2007. It is only supported for Microsoft Query based queries. For all other types of queries available in Excel you get the error “No value given for one or more parameters.” when you add a parameter to the Command text. Since the error doesn’t even hint at the real cause of the problem it took me some time before I figured it out. The thing to remember is: If you want to use query parameters, you must select Microsoft Query as the external data source when importing the data for the first time. This can’t be changed at a later time.

Microsoft Exchange supports Send As and Send On Behalf Of permissions to be granted to users for individual e-mail addresses. Sending e-mail from Outlook for these users is very simple – they just enter the desired address in the From field of a new message (toggled with the Show From command on the Options ribbon) and if they have the required permission it will be sent accordingly – either as if it was actually sent from that address or as sent by the user on behalf of the address in the From field.

If you want to achieve this from code there is a little more work involved. First of all the user must be authenticated on the server using one of the methods below:

SmtpClient smtp = new SmtpClient("smtp.domain.com");

// use user’s existing credentials
smtp.UseDefaultCredentials = true;

// pass username and password
smtp.Credentials = new NetworkCredentials("username", "password");

The next step is to set up the correct headers in the message otherwise the server will return error code 5.7.1 describing the permission the user does not have.

To send the e-mail as only the From property has to contain the desired address:

MailMessage mail = new MailMessage();
mail.From = new MailAddress("send.as@domain.com");

To send the e-mail on behalf of another user the Sender property must additionally contain the user’s e-mail address:

MailMessage mail = new MailMessage();
mail.From = new MailAddress("send.as@domain.com");
mail.Sender = new MailAddress("user.address@domain.com");

On a related note, the required permissions can be granted using PowerShell.

To grant the Send As permission:

Add-ADPermission –Identity "user1" –User "user2" –ExtendedRights Send-As

To grant the Send On Behalf Of permission:

Set-Mailbox "user1" -GrantSendOnBehalfTo "user2"

In both cases the user1 specifies the mailbox to grant the permission for and the user2 specifies the user to grant the permission to.

Today I decided to get to the bottom of the missing driver issue on my computer running Windows 7 RC. It shows up as PCI Simple Communications controller and it really bugged me since I don't have a modem or a similar device on the motherboard.

It turned out that there is a away to identify such a device from the information available in Device Manager. The first step is to open the Properties window for this device and move to the Details tab. After selecting the Hardware Ids in the Property dropdown the device identifiers are displayed.

The important ones are the numbers written after the VEN and DEV keywords. The first one is the Vendor ID and the second one is the Device ID. So in my case the Vendor ID is 8086 (from VEN_8086) and the Device ID is 29A4 (from DEV_29A4).

All that's left to do know is to go to PCIDatabase.com and enter the ids into the corresponding search boxes. In my case it turned out that it was a device from Intel - Intel Management Engine Interface (HECI). Unfortunately it doesn't have a driver for Windows 7 yet and the Vista one doesn't install. But hey, at least I know which driver is missing.

Today I've taken my new handeld GPS device for a test run. It did its job pretty well but the real challenge started afterwards when I tried geotagging the photos I've taken. I decided to use Microsoft Pro Photo Tools which have just been released with geotagging as its main feature. Downloading the track data from the GPS device with Garmin MapSource software was quick and simple. But the problems started soon afterwards. MapSource can only export track data in its proprietary format GDB which can't be used in Microsoft Pro Photo Tools.

GPSBabel came to the rescue. This free tool can probably convert files between any two existing GPS formats, at least judging from its list of supported formats. I used it to convert my data to the GPX XML format only to find out that Microsoft Pro Photo Tools have problems with it. Converting to NMEA or KML instead didn't help either. Fortunately the latter returned a strange error (Degrees must be between 0 and 90, found degree 46298501) which put me on the right track. Of course there was no such value in the KML file so I correctly deduced that the decimal separator was to blame.

The value in the file was 46.298501 but the Slovenian regional settings have comma as the decimal separator therefore the value was misinterpreted. Temporarily changing the decimal separator to dot solved the problem - the track was successfully imported immediately afterwards. This issue won't keep me from using this otherwise very useful tool with a really nice feature set. It could even fix the mismatching time settings between my GPS unit and the camera with a single setting. I just hope they address this bug soon so that I won't have to change my regional settings every time I use the program.

The only thing I still have to figure out is why the geotags somehow lost resolution when I uploaded the photos from Picasa to Picasa Web Albums. I just fixed them manually and decided to address the issue next time. Any tips are welcome.

The Xbox 360 Dashboard update released on 4th December 2007 added support for playing DivX and XviD videos natively, i.e. without installing Transcode 360 for Windows Media Center. Unfortunatelly this only works for media played directly from the dashboard and not within Media Center Extender. Since I didn't want to copy my videos to CDs, DVDs or other external devices, the only thing left to do was to setup Windows Media Player media sharing which I never had to use before.

This turned out to be more difficult than I expected - the reason being that the media I wanted to share wasn't stored locally but on a separate file server. By default such media is not shared and there are few steps one has to follow to make this work, as thoroughly explained here:

• Enable remote content sharing by adding the following entry into the registry:
  [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MediaPlayer\Preferences\HME]
  "EnableRemoteContentSharing"=dword:00000001
• Grant anonymous users access to the shared folders on the file server by adding the read permission on the folder and on the share to the ANONYMOUS LOGON user
• Modify the file server's group policy to allow anonymous access to the selected shares by listing them in the Network access: Shares that can be accessed anonymously policy in the Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options branch of the group policy tree (just run gpedit.msc to start the Group Policy Object Editor)

Not so long ago I've been called to my boss's office to prevent him losing unsaved work in a PowerPoint presentation. It turned out that when he tried to save the file to a new location the message box with the overwrite warning for some reason didn't render completely and it was impossible to close it. As it turned out at the end I could have just killed the application and restart it, since the AutoRecover feature kicked in and offered a version of the file with all changes applied.

But just to be on the save side I wanted to copy the AutoRecover files to a save location before actually killing the application. But unlike Word or Excel where the location of these files is set in the options, PowerPoint does not have such an option. After some googling I finally stumbled across a page, correctly stating that the files are stored in the %temp% folder and named ppt*.tmp. I decided to publish this info here just in case I need it again.

Once you start putting CruiseControl.NET to production use you'll sooner or later encounter the need for custom build tasks. There's only a limited set of them in the package and Executable Task can only do so much. Unfortunately there is not much information available on development of custom tasks. Your best sources will be:

• Online documentation contains an article on the subject describing the first steps to get you going. It should be your first stop.
• There's a high level architectural overview of a simple task available at Josh's Blog.
• Lutz Roeder's Reflector for .NET will be your best friend. The source of the tasks in ThoughtWorks.CruiseControl.Core will soon become your best resource.

Apart from that I feel obliged to mention a few of the most important points I've come across during the development of a few custom tasks:

• ThoughtWorks.CruiseControl.Core.Util.ProcessExecutor is a nice little wrapper around System.Diagnostics.Process class you'll end up using quite a lot.
• You can add your own information to the build log by calling AddTaskResult on the IIntegrationResult instance passed to your ITask.Run method. There are two overloads available: one accepting a System.String and another one accepting ITaskResult to which you can pass a new FileTaskResult instance to quickly include a complete file.
• If you're doing any checkins to your source control system as a part of the build you should call the MarkStartTime method of your IIntegrationResult instance afterwards to prevent triggering another build of the same project by setting the last build start time after the last checkin time.
• Make sure you use a unique ReflectorType name for your task. The service will just silently fail to start in case of a duplicate value.

This information should make your first attempts at making your own custom task a little easier.

The 1.3.0.2918 build of CruiseControl.NET has an error in msbuild.xsl file which causes an XslLoadException to be thrown when trying to view the MSBuild output in the web dashboard. One of the users was nice enough to describe the changes to the file necessary to fix the problem. Unfortunately even the latest version of the file on the CruiseControl.NET Live site doesn't include the changes therefore I'm attaching the file to this post as convenience.

Although a MSI file can bi installed by double clicking on it in Explorer or by selecting install from the context menu, you might want to start from command line to include it in a script. This can be done by using the msiexec.exe utility. Although it's parameters are well documented I had to do some searching to find a way for setting a different installation directory than the default one in case the configuration forms are skipped with the /qb option. It can be done by setting the INSTALLDIR property to the desired value.

As a future reference the following command line triggers the setup package to install into the specified directory without opening any additional configuration windows:

msiexec /i MyMSI.msi /qb INSTALLDIR="C:\Program Files\My Install Dir"