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. ;)
Related
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.
We have a solution, there are about 100 hundred projects in it. And we have around 20 installers which we created with vdproj.
I need to create WiX projects, which would create .msi instead of vdproj. I used dark.exe to generate wxs file out of msi and got binaries out of it.
I successfully created an msi file and everything was good.
But then I started thinking about it. If some of these projects are changed, will those changes be applied to the application after rebuilding of wix project? Or wxs will be referencing the old version and to update it someone will have to rebuild vdproj project to create new msi, then use dark.exe again?
I am sorry for a stupid question, it's my first time using wix and working with installers in general.
Thank you in advance
You've started on the right track. The VDPROJ outputs are .msi files, so using dark to convert those to wxs files is the right thing to do. Now that you have your wxs files (the base source file to build wix deployments), you can do away with the VDPROJ projects in your solution and only update and use the wxs files (I believe WiX has a visual studio project template available as well).
You'll have to update you wxs files with new assemblies or deliverable files as your projects change.
It is better this way then doing a wildcard pickup (something you can't technically do with WiX, anyway) as having explicit control of what goes on the target machine is preferred. I've seen many cases where developers carelessly add a reference as build output that isn't needed, and sometimes that reference cannot be redistributed per the license agreement or other legalities.
I am using WiX Burn 3.9 to create a bootstrapper (with a custom managed bootstrapper application for the UI). I'm building a tiny version of the bootstrapper (a couple of megabytes) that downloads dependencies as needed. I'm also building a version with all dependencies embedded, to support easy installation on secure networks. The /layout command line option would work for pulling down the dependencies, but my organization prefers a single, monolithic executable to keep things simple for the users.
Everything was going along pretty well until I was asked to add a 1GB virtual appliance file and associated installation readme. All the bootstrapper has to do is place them in a folder that the user specifies in the bootstrapper UI. I put the *.ova and *.htm file into a self-extracting zip executable and passed the destination folder to it on the command line. The web installer version works just fine, but then I tried to build the offline installer, with everything embedded. I started getting an error from light:
light.exe(0,0): error LGHT0306: An error (E_FAIL) was returned while finalizing a CAB file. This most commonly happens when creating a CAB file with more than 65535 files in it. Either reduce the number of files in your installation package or split your installation package's files into more than one CAB file using the Media element.
The only relevant-looking conversation about this error that I have found is here. This seems to be related to file size, not file count. I'm wondering if the problem is related to the overall size of the bootstrapper executable (which would be about 2 GB) or the size of the very large self-extracting zip executable (about 1 GB). When I'm building an MSI with WiX, the syntax for breaking things up into separate cab files is pretty clear, but I'm not sure whether the same concepts are exposed for a Burn-based boostrapper, or if it's possible to do much to embed a file of that size.
With embedded payloads, Burn uses a .cab file that it attaches to the .exe during the build process. That means there's a 2GB limit on the size of embedded payloads. There might also be a limit on how much you could attach to an .exe.
I haven't tried it but it looks like you can try attaching multiple containers by using explicit Container elements.
Unless you absolutely need a single .exe, you can also just create an uncompressed bundle. The .msi, .cab, and .exe files would be external but it works if you're creating .iso images for download (for example).
I created an MSP patch file using WiX Pyro(using purely WiX toolset). But it seems that created MSP file doesn't include files changed in content but not changed in version number. As I think, most of those files are not actually changed in main content but just rebuilt by Visual Studio. So, it may be desirable behavior that Pyro does.
But my customer asked me why files installed by the latest MSI and files updated by MSP patch are different. So, I want to know there is any way to include those files into MSP patch, or can I tell my customer that those two file sets(the latest MSI, old MSI + MSP) are the same so you can use the product safely? (Of course, I think my file version management is pretty poor and not systematic, but MSI's version rules feel too strict and somewhat inflexible to me.)
The Windows Installer file update rules are what they are, and I don't think you're going to get them changed. The standard rule is that you tell Windows the file is updated by incrementing the version, and then at install time a higher version will replace a lower version. That's the reason tools that generate patches also use the version rule - why should they include files that haven't got a higher version? Service packs, patches, hotfixes etc all work based on file versions.
If you want to use whatever file versions you like, then stop using patches and do a major upgrade that does a RemoveExistingProducts early so you get the equivalent of an uninstall of all the old files followed by an install of all the new ones.
By the way, if these are managed code files and you believe that incremnting the file version means incrementing the assemblyversion, then use AssemblyFileVersion to increment the file version and leave assembly version alone.
I have an MSI package that installs a large database file in addition to the programme components. This file is not included inside the package but is delivered beside the msi file. Up to now there was no problem with this setup. Now the database grew to a size larger than 2 GB. This throws an error upon installation (tested on Win7 machine):
"Error while writing the file: [path to database file]. Check if you have permissions for the folder."
Searching the internet showed that windows Installer seems to have a problem with files larger than 2GB. As solution it was suggested not to include the file inside the MSI but to ship it uncompressed alongside the msi. This is what we are doing already. Thus the suggested solution does not work.
Is there any way to install files larger than 2 GB using Windows Installer? This limitation seems to be a little outdated to me.
P.S.: if it helps, the installation is build using WIX but any hints on what to modify in the msi database itself are appreciated
The Windows Installer does have some old limits in it. The table definition for FileSize has a limit of 2GB and the Windows Installer uses cabinet files to compress data which has a limit of 4GB (although you can get around it by using cab-splitting).
I'm pretty sure you've hit a real max in the Windows Installer but if you have a newer version of the WiX toolset (v3.7+) you can see if cab-splitting will work for you. To try replace any Media elements you might have with:
<MediaTemplate MaximumCabinetSizeForLargeFileSplitting='200' />
That will create as many 200MB cabinets as necessary to contain your content. The only remaining question is whether the Windows Installer will understand the file when it is greater than 2GB. Best of luck!