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

[Hoover, Jacob]

Installing the same MSI twice is possible but not recommended (see Instance transforms).

Are these Native dependencies or shared dependencies?  Do newer libraries break backwards compatibility?

Wixlibs are “more better” than a MSM, but I’m not certain on the performance side. I assume you are talking a binary wixlib, correct?  http://robmensching.com/blog/posts/2008/10/10/what-are-.wixlibs-and-why-would-you-use-them/

From the looks of it, you’re not going to gain a lot with wixlib’s until a 4x feature happens, which as of now I don’t see it in queue.

https://github.com/wixtoolset/issues/issues/4266


From: Konstantin Konstantinov [mailto:ktkonstantinov at gmail.com]
Sent: Tuesday, July 14, 2020 12:26 PM
To: Hoover, Jacob <Jacob.Hoover at greenheck.com>
Cc: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Subject: Re: [wix-users] Build time reduction possibilities with binary wixlibs

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<mailto: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<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<mailto:wix-users at lists.wixtoolset.org>
Cc: Konstantin Konstantinov <ktkonstantinov at gmail.com<mailto: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<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/<http://www.firegiant.com>
NOTE: This email was received from an external source. Please use caution when opening links or attachments in the message.
NOTE: This email was received from an external source. Please use caution when opening links or attachments in the message.