Goodness is it a pain in the butt! We skirted so many of the rules and hacked up the MSI to such an extent that I feel shame. Dead transitive components add so much cruft to the MSI. And if the install has > 40k files, the thing is ungodly slow.

My ’scripts’ are C# console apps that use LINQ to XML on *.wxs and *.wxi and produce patches for each build. All is tied up by one batch file invoking msbuild.

The most tedious thing for me is keeping a good, complete account of what is going on, logging the changes and applying them correctly to *.wxs or *.wxi.

We also allow to do the things that normally break the component rules, like creating a new folder. This is done in code, in CA DLL, so we don’t break the rule ‘officially’ and still can create a minor update patch.

We then create a new component with the changed files and a new component GUID since I can create new components in a minor upgrade scenario.

This scenario above is not practical if you have a single component packed with hundreds of files and only one file has changed though.

Currently we are working on a system that will handle automation for patching. We do have patches built every night and I have perl scripts that evaluate the patch validation logs for errors and uses the errors to add entries to the Remove Files and Remove Registry Tables.

We still have a ways to go to have a fully automated system and it is a lot of work, but I think in the end it will be worth the effort.