Automating Windows Server Solutions Add-In Package Builds to Support In-Place Upgrades
My friend and fellow WHS MVP Sam Wood from Tentacle Software has just published a very long and detailed article on Automating Windows Server Solutions Add-In Package Builds to Support In-Place Upgrades. If you are a developer, or thinking of developing add-ins for WHS 2011, this is a must read.
This is how Sam starts the article:
The Windows Server Solutions SDK gives us some great new functionality for deploying Add-In packages:
- A proper upgrade process
- Client installers that can be automatically applied to any joined PCs
- EULA support
- Localization support
But, because there’s no such thing as a free lunch, the new functions come with added complexity. As I’ve discussed previously, in order for you Add-In to support in-place upgrades there are a bunch of properties that need to be changed whenever you build a new version of your Add-In:
- Package Version in AddIn.xml
- ServerBinary File Version in AddIn.xml
- Product Version in your installer project (<product>.wxs if you’re using WiX)
- Assembly File Version and Assembly Version in AssemblyInfo.cs for any changed assemblies
It’s really easy to forget one of those and break the upgrade process. So, how do we take the pain away?
What follows is my solution for build automation with WSSX files. This is only what works for me, and there are certainly other ways to accomplish the same thing, so feel free to offer your methods in the comments below.
This is going to be a long one so go grab a coffee!