[wix-users] Build time reduction possibilities with binary wixlibs

Konstantin Konstantinov ktkonstantinov at gmail.com
Tue Jul 14 10:26:01 PDT 2020


Hello Jacob,
Thanks for the reply!
It totally makes sense to put the shared stuff in a separate MSI. However,
as far as I know, you can't install the same MSI twice
to different folders. And since the products install to different folders,
it implies putting the common MSI content to a common folder like
CommonFiles/3dpartyLibs/ and/or messing with sxs/app manifests. Every
product is using the same version of the 3rd party libraries now, but this
will change soon. So it means potential complications from dll versioning.

That's why the preferred approach to us is to keep the dependencies
deployed with each product in the respective install folder. In this
direction it makes more sense to compress the libraries once into separate
binary wixlibs for each library version and consume whatever is required by
the specific product MSI. I understand that for MSM the linker might need
to decompress and recompress the module to merge it in the Installer. But
with binary wixlibs there is more setup information available inside and at
least to me, it looks like the fast path should be possible, just as having
the content already in the cabinet cache. The difference being that with
the binary wixlib, there is no "source" content to check for cache validity
- just take the cabinet inside the lib. This way not only the installation
setup, the source data, but also the compression result will be reused as
well.
I wonder if I am doing something wrong to trigger the cabinet recompression
in this case. (no cabinet cache)

If there is a way to install MSI contents twice to separate locations,
then probably packing an MSI for each version of each 3d party library is
also a way.
Please, correct me if I am wrong in any of these assumptions.

Thank you for your time!

Konstantin












On Mon, Jul 6, 2020 at 6:07 PM Hoover, Jacob <Jacob.Hoover at greenheck.com>
wrote:

> If you are deploying via a bundle, why not make the 3rd party stuff its
> own MSI and just put it in the chain?
>
>
>
> *From:* wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] *On
> Behalf Of *Konstantin Konstantinov via wix-users
> *Sent:* Friday, July 3, 2020 4:00 AM
> *To:* wix-users at lists.wixtoolset.org
> *Cc:* Konstantin Konstantinov <ktkonstantinov at gmail.com>
> *Subject:* [wix-users] Build time reduction possibilities with binary
> wixlibs
>
>
>
> Hello everyone,
> At work I am exploring build time reduction possibilities with Wix. In
> the current setup we have 36 mins of build time for 7 product installers
> (MSI) which is considered too much for the CI pipeline. Looking closer at
> these timings I found out that Wix spends most of the time
> compressing third-party libraries that rarely change. They account for
> around 80% of each installer payload. So naturally using the linker cache
> helps a lot -> x9 build time reduction on average. However, since we build
> our products in parallel, it means that we have to use 7 different cabinet
> caches for the same libraries. Also the general direction in the build
> process is to clear any intermediate state between rebuilds and use caches
> as rarely as possible to avoid stale data creeping in.
> I was wondering if it is possible to use binary wixlibs directly without
> a linker cache and rebuild them separately only when updating the 3rd party
> libraries? This way we can keep them even under version control.
> I tried it and, unfortunately, I'm stuck with several problems with this
> approach that practically negate the performance benefits. Each library is
> placed in a separate binary wixlib defining 1 separate cabinet. The
> problems are:
> 1. Cannot control the level of compression for the library tool
> (lit.exe), seems to default to mszip at all times regardless of the <media>
> setting.
> 2. The MSI linker (light.exe) seems to decompress and recompress the
> cabinet payload from the binary wixlibs when building the final MSI if the
> linker cache is not used.
> 3. .pdb generation for the MSI takes quite some time with binary wixlibs
> - this is probably a misconfiguration on my side or a bug.
> Environment: Win10, Wix3.11.2, MSVS2019 (16.5.5) + WixExtension
>
> I have posted a question in stackoverflow with a description of a
> simplified setup, time measurements and different setup options that I
> tried. Sofar nobody has commented on it.
>
> https://stackoverflow.com/questions/62682382/reducing-build-time-with-binary-wixlibs
>
>
> Any help with any of these 3 points would be greatly appreciated!
> Thank you for your time.
>
> Konstantin Konstantinov
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/
>
> NOTE: This email was received from an external source. Please use caution
> when opening links or attachments in the message.
>



More information about the wix-users mailing list