How to create a Wix patch in combination with Heat?

Question

I am a developer on a large system (> 100 projects in solution,> 100,000 LOC,> 10 services, ...), and in the past this installation was installed using wix, and it worked fine. Now I need a way to fix parts of the (Minor Upgrade) system and complete several problems.

My Current Wix Setup is as follows:

• I have VS2010 and Wix3.6 Toolset and TFS2012 to put it all together and get the installer
• I am using the project type of the installation library for the service
• I use exactly one installation project to bring everything together and get one installer for the entire system.

Cannot change this setting.

Setup library projects are installed as follows:

• I use the heatbuild msbuild task to generate components and files, and I use preprocessor variables to change file paths.
• I need to change the file paths, because it should be able to install the installer on the local developers system and build the installer in the tfs build system, which is different from the folder structure.
• TFS always uses the same directory to compile subsequent versions of the software and relocates the output after successful compilation to a unique folder structure.

Now I need a patch. I created Patch.wxs and called it candle and light. I called the torch to get the difference file. And finally, I want to create a patch with pyro. Everything worked fine with a simple test project, but on a large system Pyro has a problem that he cannot find the files to install. Through my setup (see above), I have to use preprocessor variables and have the full path in my wix output file (for example: C: \ builds \ myproduct \ prodct.exe as the source of the file). After moving the TFS output to another location, this path is no longer valid. I tried using -bt and -bu for pyro, but this only works for relative paths or for named binding paths.

Now, I wanted to modify my wix project project to use named binding paths rather than preprocessor variables, but that doesn't seem to be possible. heat can only use preprocessor variables or wixvariables, but it does not seem possible to use bindpath variables. heat provides the -wixvar switch, which should create binder variables instead of preprocessor variables, but I'm not doing anything.

Now I tried to use wix and not use preprocessor variables in heating mode and tell the light to the -bu-bt switches where you can find the files. But if I do not set the preprocessor variable, the resulting files look like Sources \ product.exe. I cannot get rid of these Sources. I know that I can convert all xml to xslt and delete Sources, but this is a workaround that I would follow if there was no other solution. This would also mean that the problem is with the wch toolchain.

It seems that pyro only supports bindpath variables, and heat only supports the preprocessor and wix variables. It seems really crazy because how should they work together?

How to create a patch if I use lights, a candle, heat, a torch and pyro, and if the original assembly paths have changed (which is very common in the assembly system) and paths to files with heat are created and, therefore, be fixed or a preprocessor or wix variables?

Answer 1

As you discovered, heat not intended to be used in a patch script. Only in the latest versions of the WiX toolkit did the generated GUIDs reach the point where there was even a chance that heat could successfully build the output, which would be patch. Still, work needs to be done there to make a correction where heat used well.

Ultimately, I believe that the answer is to simplify the "source source" problem. It is very difficult to configure all the correct binding paths and make a correction, which is a complex problem, even more difficult. We kicked a few ideas, but nothing came together.

You can always use hotfixes based on the graphical admin interface. This is slower, but it may be easier to get the "source" and "target". However, this path does lose filtering.

Basically, we need to work a bit on the fix scripts to make it a lot easier.

PS: The "source" in the path for the File/@Source attribute is an alias for the "default binding". Here you can use bindpaths.