Friday 23 September 2011

SP2010 Continuous Integration–pt 4: Assembly versioning

The 4th article in our CI with SharePoint 2010 and TFS series is now live on the official SharePoint Developer blog. This post is a quick overview, but the actual article can be found here - Configuring Versioning of Assemblies in SharePoint Automated Build. In this episode we cover how to introduce assembly versioning to your automated build process. The benefits of versioning code are widely documented, but in my simple mind I think of it like this – if you don’t have versioned assemblies, how can you easily tell which version of code is running in a given environment/customer/product? The answer is you can’t – at least, not without resorting to Reflector or some other decompilation tool and literally scanning code. And that’s really not efficient nor effective – far better to put something in place once, and forever be able to determine the version by looking at the file in Windows Explorer. I’d argue that most pure .Net development shops tend to have adopted assembly versioning a long time ago, but again it’s one of those things which is somewhat behind in the SharePoint world due to the other complexities which come with it.

Additionally, versioning in SharePoint can be a very bad idea if not done appropriately (no doubt a few people tried and got bitten by this). Version numbers are stored in many places inside SharePoint, and using typical versioning approaches will result in a broken application. Instead, I always recommend that a secondary version number such as AssemblyFileVersion is incremented with SharePoint.

So if we’re agreed that it’s worthwhile, how do we adopt it? It would be nice if TFS had some simple switch, but that’s not the case up to and including TFS 2010 (personally I’ve no idea about future versions). Implementing versioning requires some customization of the build process (which we introduced in the last article, Creating your first TFS Build Process for SharePoint projects), and essentially we need to drop in a custom workflow activity which takes care of the versioning step. I’ve written such an activity and published it on Codeplex at (others exist too). The article explains how to implement the sample to perform versioning in the right way.

That link again is Configuring Versioning of Assemblies in SharePoint Automated Build.

The next article will be “Deploying WSPs as part of an automated build”.

No comments: