Rebuild MSI if only updated files - wix

I have a setup where I'm building the MSI along with a CAB containing all the files. I also need to build different MSIs for different languages. I have already built all of them and they all share the same CAB file.
Recently I updated a couple of files and rebuilt one of the MSIs (which also rebuilt the CAB file).
Do I need to rebuild every MSI as well?

Yes, because the MSI contains details about the files that will be installed, such as file size, version, file hash. These need to match with the files being installed.

Related

Wix Burn Loose File Install

Copying of license files using Wix 3.10.2? We have a requirement where we need copy some license files after the installation of the webapplication to IIS. Copying of license files will be the last in the sequence. The license files will reside next to the burn (bootstrapper) setup.exe. This way we can control what license file need to be installed based on the user. I am trying to understand if there will be an issue with number of license files reside along with .exe? Is there a custom action to pick files that are not part of the msi or exe?
1) There will not be an issue with number of license files residing along with exe
2) Using the Media element without a Cabinet name you can specify that certain files will neither be inside a cab or embedded into the msi, no custom action needed. See http://wixtoolset.org/documentation/manual/v3/xsd/wix/media.html
You may need to be more precise about exactly when you want the copy to occur. Your original question says "after the installation" which implies that the install has finished and that your generated MSI is no longer running. but in a later comment you say "during the install".
If after the install is what you want, then you could add a custom executable to your Burn bundle that will do whatever you want. In many of these kinds of situations the application that needs the file just goes and gets it with help from the MSI saying where it was installed from, or by using the SourceList capabilities of Windows Installer to get the location.
If you want to copy files during the install then the CopyFile element is probably what you need. It has wildcard capability to define the files you want to copy. Your source location will be the SourceDir property and the destination will be one of your defined directories. Note that the files will not be uninstalled when the product is uninstalled.
WiX Copyfile:
http://wixtoolset.org/documentation/manual/v3/xsd/wix/copyfile.html
I had to use native bootstrap that comes with Visual Studio SDK. With the bootstrap you can also create pre-requisite like installing .net. This worked for my requirement. Also there is a msbuild task so that you can automate it. Used setup project to create msi and VS bootstrap to create setup.exe

WiX Bundle: Determine point in time to start registry search

I want to run two msi setups and afterwards install some files to the their locations. As the files I want to install are the same and big in size, I don't want to add these files to the msi's.
So I have a WiX bootstrapper bundle that installs the msi packages. These msi package write registry entries about their install location. Then, I want to read the install locations within the bootstrapper and copy the files to these locations.
My problem is, that the util:RegistrySearch is performed at the beginning. So it fails due to the non-existing registry entries.
Can I somehow determine the point in time to run the registry search? Or is there any other possibility to install the files from my WiX msi script without adding them two times to my bootstrapper?
This is unfortunately impossible.

Performing rollbacks with Wix

I'm currently generating two msis using Wix let's call them A and B. I install A to a directory C:\test and then I install B to the same directory. Some of the files will be overwritten when the second installation happens.
So, how would I go about restoring A to its original installed state while removing every trace of B? I know msis can do rollbacks if for example, the installation of msi B fails, but I read that if the installation is successful, the rollback script etc is deleted.
Any help would be appreciated.
Thanks in advance.
I don't think that your approach is correct. Why are your packages installing files in the same location? Are they shared files? If they are, you can use the Windows Installer component sharing mechanism:
make sure that these files use the same components in both installers
these components should have the same names and GUIDs in both installers
when package B installs over package A, Windows Installer will use a reference count for the shared components
the original files are not overwritten
the shared components are removed only when both products are uninstalled
If they are not shared files, why are you using the same location for different file versions?

How does Burn in WiX 3.6 bundle MSI files into an .exe?

I'm interested in knowing how WiX is bundling the EXE files created with Burn. I know that creating a self-extracting EXE file is pretty straightforward, having done it a million times in WinRAR. What directory is the EXE file being unpacked to, and how is the installation writing that location into Add/Remove Programs?
Also, how is the UX file being kept around for the uninstall? And even more interesting, what goes on during an upgrade?
Burn doesn't create a typical "self-extracting .exe" that unpacks the contents then launches. Instead, it extracts the bits it needs (the UX or bootstrapper application) to a temporary directory and then caches the packages that are needed when they're needed. That way, no time is wasted extracting packages that aren't used.
The cache directory is named "Package Cache" and stored in an appdata folder, which one depending on whether it's a per-user or per-machine package.
There's nothing special about upgrades, except that when one bundle upgrades another, the previous bundle's cache is removed.

Switching from WiX 3.0 to 3.5 decreased msi size from 100Mb to 4Mb?

After upgrading my installer build to WiX 3.5 the msi size fell from 100Mb down to only 4Mb! At first I thought some files were excluded from MSI, so I ran light.exe 3.0 and 3.5 with -v (verbose) and -notidy (to keep the temp files) options, checked the cab files, and indeed in case of 3.5 the cab file was 3.8Mb while the 3.0 produced 98Mb. Looking inside the cab, all the files seem to be present. Tried extracting both cabs -- the output looks identical. Finally, still not believing my eyes I installed the 4Mb MSI and it worked! What can explain such a drastic difference? My current theory -- perhaps the new WiX uses new CAB compressin logic which detects duplicate files and creates references instead of adding the file multiple times? The MSI linking time dropped significantly as well... My program consists of 20+ folders with pretty much same DLLs duplicated in all of them...
Wix 3.5.0619.0 included the following change (from http://wix.sourceforge.net/releases/3.5.2519.0/history.txt):
Smart cabbing now catches ALL
duplicate files, not just ones from
the same source path (based on file
hashes).
I have also observed a similar reduction in installer size after an upgrade from Wix 3.0 to 3.5. The above change would account for this, as there is some duplication in the files our installer is delivering, and these would only be picked up by file hashes not source paths.
Did you have different source paths in your 3.0 and the same source path in your 3.5?
WiX Smart Cabbing
Can you share the MSIs somewhere (feel free to contact me offline if you prefer, see http://robmensching.com)? There are no changes that I know of in WiX v3.5 that could cause that sort of drastic change... unless your .wxs files changed... or there is a bug. ;)