Making an MSM from whole cloth – Series Intro

Not too long ago, I was asked to provide a set of merge modules for an external team. The restriction was that they could accept an exe whose output was the merge module in question, and it had to generate stable – based on the content – component IDs. I’m being cagy because the team in question hasn’t hit RTM yet, I don’t want to steal their thunder.

My first inkling was to use the excellent WiX tools. I’d have my tool cobble up a .wxs file and CreateProcess on both "light" and "candle", creating the "all in one" tool experience the team wanted. Here I was, coding along, when the team in question came back and said "Sorry, we don’t think we can support using WiX in our build process either directly or indirectly." Enter roadblock number one. I’d never used the MSI APIs to generate modules, let alone interact with them! Several hours and hundreds of links followed on MSDN later I was headed down a path of hand-creating the entire merge module from scratch – cabs and all.

The most frequent criticism I have about our documentation is that while it provides small use cases for individual APIs, it’s rare (outside the Crypto docs, which are excellent) to find an end-to-end all-encompassing demo for complex use cases. All the items I found were disjoint micro-samples about how to read and query MSI databases and what - at a broad level – a merge module should contain. So, almost nine months later, four intensive test cycles, three frustrated PMs, and two major design changes later, it’s done. I plan to share my long strange odyssey through MSI-land in a series of posts over the next month – going from "what tables do I need?" to "what do you mean you want to merge the cabs?"

And yes, this time the entries will get written and posted, as I’ve scheduled myself an hour a day this week and next to write installments.