As a continuation of my last post, I thought some of you .net developers may be interested in hearing about some of the issues I ran into when strong naming.

Admittedly, this is my first real attempt at using strong naming as it’s intended and therefore I just wasn’t aware of a few things when I was writing the code for Chef. Two days ago I created myself a strong name key (sn -k keyfile.snk) to sign my assemblies with. Due to the obfuscation step I need to do between compile and packaging, I need to delay sign the assemblies.

In an exercise in curiosity I decided to sign the assemblies with the public key half of my keypair and keep the private key “secret”. Which really means just not kept inline with the sourcecode, but rather living in a key container in the machine store on the build box. This process was mostly problem-free, I used the sn.exe utility to: create a keypair; import the keypair into a key container; extract a public key from the key container; tell .NET to allow me to run partially signed assemblies with that public key token (sn -Vr *,) for debugging purposes. It all went well until I went into visual studio and told it to use the public key for signing – it kept telling me that it was password protected and prompting me for the password. I never put a password on it.

So to get around that, I did the first step (creating the keypair) from Visual Studio and gave it a password, then it all worked just fine.

One feature in Chef is the ability to create bookmarks. In my ignorance, I was simply using the BinaryFormatter in .NET and serializing to disk an array of these things for loading later. Little did I realize that all of the version information for the objects is written out – and if the objects live in a strong named assembly and the assembly version changes, it cannot deserialize! There’s supposed to be a way you can get around this, by setting AssemblyFormat on the formatter to Simple but it continued to write the version information. I also tried the route of using a custom Binder during deserialization and that didn’t work either.

As a result, last night I rewrote that code to serialize/deserialize the information myself with XmlWriter and XPathDocument rather than rely on .NET. Version issues gone. That’ll definitely be something I’m not likely to forget anytime soon. I need to rewrite one other small area this weekend for a similar problem, then I can move on. All that’s standing between me and Beta 2 is some thorough testing, a website update, and a file upload. Should all happen this weekend.

Several hours today were spent advancing my automated build process for Chef. I’ve had CruiseControl.NET building the software for months now but I’ve had a gaping hole in the processes that has been staring at me since I started it.
What is this hole you ask? Version numbering.

Why is versioning so hard in this day and age? Seriously. With .NET there are all these really nice and easy attributes that all you have to do is type in the version string you want your assembly/binaries to have. That works really well, until you want those numbers to be dynamic – then it requires modifying a sourcecode file with a new hard coded string. But what about 1.0.*? you ask, referring to the ability to have the compiler generate parts of it for you. Well, what real good is it to have version numbers that you don’t control? If they get generated by the compiler it just makes everything difficult – like translating between a version label from CruiseControl to the state of source control at the time of the build. Maybe I’m missing something here, but I don’t think I am.

Another versioning issue is setup projects. The setup projects created in Visual Studio have a version number, product code, and upgrade code. Counter to intuition, the upgrade code is the same across versions for a given product and it’s the product code that changes between versions. Sooo, if you bump the version number you also need to create a new Product Code guid. Again, there’s no way (that I know of) to do this via command-line. Microsoft thinks you should open the setup project and bump the version number manually. They even go as far as prompting you to create the new Product Code guid when you do this. Microsoft, the creator of the great tool that is Visual Studio, make it very hard to do the Right Thing and have automated builds. Tisk, tisk.
And finally, the version string has implications on product keys – both generation and verification. For instance, if Suzie buys Chef 1.2, I need to have a way to have that license key work for 1.2.5, 1.4, and 1.9; but not 2.1. And I need to be able to forget about the details rather than think about it every single time I create a release. (Chef Beta 2 is days away, by the way).

My solution to these problems required a little planning, a little coding, and a lot of time waiting for test builds to be created. My process is as follows.

• I go to the CruiseControl.NET Dashboard website and click Force to initiate the build.
• The last successful build label is incremented (from 0.9.2.2 to 0.9.2.3, for instance).
• The latest sourcecode is retrieved from the Perforce depot
• The code I wrote tonight gets executed on the sourcecode tree, passing in the newly incremented build number

• A new product code guid is generated
• Every AssemblyInfo.cs file is edited and all AssemblyVersion attributes are changed to use the new version number
• The specified .vdproj files (Visual Studio setup projects) are edited to modify the ProductVersion with a trimmed version of the current build version/label. The new ProductCode is also inserted
• Visual Studio is called upon to perform the compile.
• CruiseControl puts the generated installation packages out on the network
• A sourcecontrol Label is created in the Perforce depot, denoting the state of the sourcecode at the time of the build.

And that’s it. With a single click I have installation packages created with no further involvement. The files included in the package all have a version number that I can trace back to a CruiseControl label (to view build logs and in the future unit test results) and then back to a Perforce label with the same name to view the sourcecode files at were a part of the build. I’ll then also be able to compare those file versions with the recorded version numbers of bug fixes in FogBugz – something that will surely save time once Chef is in the wild.

Microsoft, please please please make this better in the future.