Speed up Build-Process of WiX-Installer

后端 未结 3 674
轻奢々
轻奢々 2021-01-18 21:15

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

3条回答
  •  醉梦人生
    2021-01-18 21:40

    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.

提交回复
热议问题