I’ve been away for a while, though I’ve barely left the Microsoft campus. As we prepare for Visual Studio 2005 Service Pack 1, I’ve been very busy with issues: especially an issue with the size of the patch.
Visual Studio is probably the biggest product (in terms of the number of files at least; I do know of a couple products using Windows Installer for a smaller set of gigantic files) to use Windows Installer and we have a lot of editions: 13 non-Express editions in 9 languages currently. Recall from What’s in a Patch that there exists a pair of transforms for every product targeted, based on validation bits for the embedded transforms. Add up all the editions for all the languages and consider how much information is changed (mainly file sizes and versions) and what comes out of our patch build system is a very large patch. We’re solving that in practical ways by producing smaller service pack patches targeting a smaller set of SKUs, with separate service packs for Express editions.
This also raises another issues that may affect a lot more installation developers: the size of your binary custom action server DLLs. While files are typically shared in a common cabinet streamed into the patch file, embedded Binary table records are in the transforms themselves. Even if a binary record was the same, it is duplicated across every transform for every targeted product. When writing custom action server DLLs, consider breaking functionality up into multiple, smaller DLLs so that you can update custom actions without adversely impacting the total size of your multi-product patches.
I do have several blog posts planned including one to hopefully help clear up some confusion about what products our patches actually target and will be releasing those over the next few weeks.