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).
Related
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
My existing WIX works fine. It allows the user to select a number of features, and when the user proceeds after feature selection, it runs a customaction to install the files using command lines tools. (My features relates one to one with files that just happen to be VSIX files that are installed using VSIXINstaller.exe from the command line customaction).
This has been working fine for months, and to date it has included all the files in the installer package itself. The files are first put on disk, and then the command line customaction is run on them locally.
However, my installer has grown quite large to download on its own (because it includes all the feature files that could possibly be installed), and it is preventing people bothering with the download. Becuase most of our users will only select one of the features (not all), what I want to do is host the individual files online somewhere at know URLs, and change the installer so that depending on what features the user selects, download each feature file in turn, save them to the same local folder and run the same cutomaction on them (like before).
So really this is just a change to the installer that already works file when the files are packaged within it. Now instead of having the files within it, they are fetched from a URL first.
Can anyone give me some guidance how to do this?
I'm not sure that you should be using Windows Installer at all but you are benefiting from the feature selection tree. If you are willing to replace that with a custom GUI (e.g., with WinForms or WPF), you could use a WiX Bootstrapper project. It provides for installing ExePackages with downloadable payloads.
You could also split your MSI into one per feature and use those with the bootstrapper.
See this demo, this article and the WiX source code for WiX's bootstrapper.
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!
I have a Wix 3.6 managed bootstrapper in which the user can select individual packages to download and install. I want to show the download size of each package. How can I access the file size of each packages in the Bundle?
I guess this information is available somewhere in the Wix framework (because the file hashes are used to validate the downloaded files), but I did not find it.
I have an idea for a workaround, but it would be more implementation for me:
Have a wxs file generated programmatically that contains Variable elements containing the file size of the packages. Those variables would be read by the bootstrapper.
When your bundle is created, a BootstrapperApplicationData.xml is added to the bundle. That XML file contains a lot of metadata about the bundle and contained packages. Your bootstrapper application code can load this file by looking in the same direcotry as your bootstrapper application dll lives.
I did not found how by using the burn API, but I implemented my own workaround:
If the local file is present
query the file system
else
query the web server
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.