For my Wix project I am harvesting 4 directories, via the pre-build-event of visual studio, which will result in about 160mb of data, and about 220 files, but the build proc
For us, the vast majority of the time was spent invoking light
(for the linking phase).
light
is very slow at compressing cabinets. Changing the DefaultCompressionLevel
in the .wixproj from high
to mszip
(or low
or none
) helps a lot. However, our build was still too slow.
It turns out that light
handles cabinets independently, and automatically links them on multiple threads by default. To take advantage of this parallelism, you need to generate multiple cabinets. In our .wxs Product
element, we had the following that placed everything in a single cabinet:
It turns out you can use the MaximumUncompressedMediaSize
attribute to declare the threshold (in MB) at which you want files to be automatically sharded into different .cab files:
Now light
was much faster, even with high
compression, but still not fast enough for incremental builds (where only a few files change).
Back in the .wixproj, we can use the following to set up a cabinet cache, which is ideal for incremental builds where few files change and most cabinets don't need to be regenerated:
$(OutputPath)cabcache\
True
Suppressing validation also gives a nice speedup (light.exe spends about a third of its time validating the .msi by default). We activate this for debug builds:
True
With these changes, our final (incremental) build went from over a minute to a few seconds for a 32 MB .msi output, and a full rebuild stayed well under a minute, even with the high
compression level.