How to create a Wix patch in combination with Heat?

Question

I'm developer on a big system (>100 Projects in Solution, >100 000 LOC, > 10 Services, ...) and did the installation of this system in the past with wix and it worked fine. Now I need a way to patch (Minor Upgrade) parts of the system and run into several issues.

My Current Wix Setup is as following:

• I have VS2010 and Wix3.6 Toolset and TFS2012 to Build the whole thing and get an installer
• I'm using a Setup Library Project Type per Service
• I'm using exactly one Setup Project to bundle things together and get one installer for the whole system.

It's not possible to change this setup.

The Setup Library Projects are set up as following:

• I use the heat-directory msbuild task to generate the components and files and I'm using preprocessor variables to modify the file paths.
• I need to modify the file paths because it must be possible to build an installer on the local developer system and to build the installer on the tfs build system which is different in folder structures.
• The TFS uses always the same directory to compile subsequent versions of the software and moves the output after successful compilation to a unique folder structure.

Now I need a patch. I created the Patch.wxs and called candle and light for it. I called torch to get the difference file. And finally want to create the patch with pyro. Everything worked fine with a simple testproject, but on the big system Pyro has the problem that it can't find the files to install. Through my setup (see above), I must use preprocessor variables and have a full qualified path in my wix output (for example: C:\builds\myproduct\prodct.exe as file source). After moving the TFS output to another location this path is not valid anymore. I tried to use -bt and -bu switches for pyro, but this does only work for relative paths or for named bindpaths.

Now I wanted to change my wix project setup to use named bindpaths rather than preprocessor variables, but it seems that this is not possible. heat can only use preprocessor variables or wixvariables but it seems not to be possible to use bindpath variables. heat provides a switch -wixvar which should create binder variables instead of preprocessor variables but I does exactly nothing.

Now I tried do use no wix and no preprocessor variables in heat and tell light per -bu -bt switches where to find the files. But if I do not set a preprocessor variable the resulting files look like Sources\product.exe. I can't get rid of this Sources. I know that I can transform all the xml with xslt and remove the Sources but thats a workaround which I would only implement if no other solution is possible. This would also mean that there is a problem in the wix toolchain.

It looks like pyro does only support bindpath variables and heat does only support preprocessor and wix variables. This seems to be really crazy, because how should they work together?

How can I create a patch if I use lit, light, candle, heat, torch and pyro and if the original build paths have changed (which is very common on a build system) and the file paths are created with heat and therefore be fixed or preprocessor or wix variables?

Answer 1

As you've found heat wasn't designed to be used in the patching scenario. It was only in recent versions of the WiX toolset that the generated GUIDs got to a point where there was even a chance that heat could successfully build output that would be patchable. Still need to do work there to make patching where heat is used work well.

Ultimately, I believe the answer is to simplify the "original source" problem. It is challenging to get all the bindpaths set up correctly and that makes patching, which is a hard problem, even harder. We've kicked around a few ideas but nothing has come together yet.

You could always use admin image based patching. It's slower but can be easier to get the "original source" and "target" laid out. That path does lose filtering though.

Basically, we need to do a bit more work in patching scenarios to make it much easier.

PS: "Source" in the path for a File/@Source attribute is an alias for the "default bindpath". You can use bindpaths there.