I am using Wix Toolset v3.7 to create an MSI package for an application.
The problem is that one of the files to be packaged has a size more than 4 GB.
As a result the MSI generation fails with this error:
some_file.dat" is too large, file size must be less than 2147483648.
I have searched for a solution to this problem but haven't got any specific pointers yet. Does anybody know how to approach this using Wix? Any way a file can be specified to be split into cabs and remerged on unpacking?
Per File Table (Windows)
The FileSize column is a DoubleInteger which can only represent –2,147,483,647 to +2,147,483,647 bytes. There are also other limitations in the size of a CAB and size of an MSI. These are someone annoying limitations but it is pretty rare an installer needs to ship a file larger then 2GB.
WiX is built on Windows Installer so you are kinda stuck. Is your installer distributed via media? You might want to use a custom action copy the file manually. Another thought would be to split the file into pieces and then use a custom action to join them. Tough choices.
1) You could split the file with a common zip/package tool before the msi build, and use that tool as a custom action to put them together. Of course you can write such a tool on your own too. Then the parts of that file are handled in a standard way by MSI (before your final merge action comes).
2) If you don't need all the msi stuff for that file you could just avoid putting the big file in the msi and just use a tool to build a selfextracting .exe. This could start the msi and copy the file itself by a script. Maybe the easiest way.
3) With the DuplicateFiles table in MSI you can try to copy the file as a custom action in MSI itself. With or without the selfextracting .exe idea. Without means that the big file stays uncompressed besides the .msi. With means you have all compressed in that .exe.
Related
Disclaimer: I'm fairly new to burn...
The .exe files created by WiX Burn bundles are some type of self extracting zip archives, however they seem fairly opaque in structure and I cant find any documentation on them. For example in 7zip a Burn .exe looks like this:
Whereas a traditional .vdproj bundle (and other bootstrappers I have seen) include the bundled files verbatum in a traditional file system.
QUESTIONS:
Is the output format documented anywhere?
Is there any way to
recover the contents without installing? EDIT it seems dark.exe can do this, so 2a. is there anything outside the WiX toolkit...
Is there any way to
change the output format?
Thank you.
NB The reason I ask is that there are many circumstances (corporate IT departments say) where people extract the .msi files out of traditional bootstrappers to wrap into their own logic / examine the bootstrapper contents as part of an approval process.
No, the format for an attached container is undocumented (intentionally, so we can change it later). Today, in WiX v3.10, it's a .cab file attached to the .exe.
(a) It's possible but there are no such tools today (that I know of) other than Dark.exe.
No, not today. Obviously, you could use external payloads so they're not attached to the .exe.
I have an .ini file with configuration. I need to check if it exists in new installation to avoid creating it again. Besides if the new .ini have new fields add to the existing file.
Don't install an ini file as a file, but convert the entries into IniFile Table entries. This allows all ini file changes to be treated as "atomic change units" that allows proper merging and rollback via built-in MSI mechanism. You avoid all custom action complexity.
As Chris points out in his major upgrade comment: do things the right way in Wix / MSI and you avoid a lot of problems that start to pop up when requirements change or updates get complicated. IniFile updates implemented the right way are robust and simple to deal with.
In Wix you use the IniFile Element to achieve this. All merge capabilities, rollback support and advanced ini file handling comes along for free. All you need to do is to define what needs to be added or modified in the ini file during your installation. It will also be created if it is not there in the first place.
Using the IniFile element may look harder than it is. Here is a sample. You can also have a look at the well known Wix tutorial here.
All MSI-experts keep repeating this advice: never use a custom action to change a system if there are equivalent built-in MSI constructs.
Set NeverOverwrite="yes" on the .ini file's component and then handle the update via a custom action.
Edit: Generally it is much better to use the IniFile table as explained in my answer since you get rollback and merge capabilities. However, some people prefer the INI file installed as a file to allow easy modification of the file from outside the MSI file. Though not preferred, this does allow people to "hotfix" the INI file directly on the installation media location. Teams can use this to have the installer pick up the latest INI from development. There are technical problems with this that can be handled via a custom action (most significantly file replacement issues on install). It is also possible that an INI file can feature non-standard elements and formatting that doesn't fit in the IniFile table (rare, but possible - people with sense then use a different file extension than ini). As already explained, I would strongly advice against updating INI files via your own custom action, unless you are doing something very special - that's actually needed. It is complicated to implement and to get right.
I would suggest having 2 INI files. One that the installer owns and one that the application / user owns. The installer can always overwrite it's INI file and never worry about stomping on user data.
We are developing a software tool that is sold to other software companies to be
redistributed. We deploy our software with WiX. We get some requests from our
clients that they would like to use their own style for the msi (mainly their icons, images
and titles). We do not want to let the customers do the packaging themselves since this
is too sophisticated. Is it possible to create a msi package with WiX, where some
resources as images and strings can be loaded dynamically from external resource later on.
I found Wix: Dynamically Add Features which gives
a solution for dynamically add functionality, but not to change existing parts.
Ok, so here my comment as answer (I hope it was helpful ;-)).
As I don't know the exact use case, I would:
Create the base MSI containing all binaries, bitmaps and icons (in the Binary-table)
After building the MSI, invoke the VBS-script rerplacing the binaries and bitmaps with the ones of your customer.
Send the modified MSI to the customer.
If the changes are rather static you could also create a transform file (.MST) containing all the modifications for your customer. You can then merge this transform into your base MSI file using e.g. WiMerge.vbs from the Windows SDK located in v7.1\Samples\sysmgmt\msi\scripts. This would even simpler and can easily be integrated into your build process.
I am someone with little to no experience with wix and I am trying to support Windows also for the component I am responsible for. I am trying to create merge module for a set of files that my product generates. These files exist in numerous sub directories. I was wondering how I can create a single component ID for all the files in the entire tree. I am not worried about minor upgrades as that is something I am not going to be doing. I am trying to avoid generating numerous GUIDs for each of the file.
Also is there any way I can change the name of the root directory I want the files to be installed. Currently, in our build system the files I want to install end up in a directory name "install". In the wxs file generated by heat it comes up as install. I was wondering if I could change it to the actual product name instead of "install".
Use one file per component - this avoids all sorts of problems (except .NET assemblies spanning multiple files). See the following thread: One file per component or several files per component?
Wix is a great framework for creating installers, but it has a steep learning curve. I strongly recommend you read a few sections of this great, online tutorial: https://www.firegiant.com/wix/tutorial/
If you are a "sample based tinkerer", you can find an even quicker, sample based tour in this article: http://www.codeproject.com/Tips/105638/A-quick-introduction-Create-an-MSI-installer-with
Wix is hands-on. Just focus on the samples, and focus on getting the components created and a major upgrade set up:
How to implement WiX installer upgrade? (modern, convenience way)
How to get WiX major upgrade working? (legacy way - more flexible, less convenient)
http://wixtoolset.org/documentation/manual/v3/howtos/updates/major_upgrade.html
Once you got that running the rest of the details fall into place by reading the documentation for whatever feature you need. Using Visual Studio / Votive with intellisense ensures that you can learn as you go with features such as shortcuts, ini files, xml files, dialogs, etc...
Another top tip is to use dark.exe (part of the Wix toolkit) to decompile existing MSI files. This yields Wix XML with code you can copy and paste into your own Wix files. I use other MSI tools to compile such MSI files, and then copy the sections I need into my Wix file - just to speed up the process of creating the Wix XML. Studying the decompiled XML is very educational - a real time saver.
UPDATE, May 2021: Some more links:
WiX Quick Start - Very long version
WiX Quick Start - Short version
If all the files are going to the same destination folder, then you can create one single COMPONENT with all the FILE within it. There is nothing stopping you to do that. You can then just create one GUID for that component. Also read these answers which talks about the advantages vs disadvantages of one component vs multiple components before you implement it: Answer1 Answer2. To Summarize:
You will have trouble with minor upgrades/repairs. If a component is
being updated, only the file designated as the KEYPATH is checked to see if
it is out of date: if it is up to date, all the others are ignored.
You'll also have difficulty if you want to add or remove files from each
component. Once released, a component is immutable (in terms of what files
are in it). The only way to update it without breaking component rules would
be to effectively remove and install the a new version of the MSI.
Understanding the component rules is key in Windows Installer and one file
per component makes the component rules easier to work with, which is why it
is the recommendation of many people here.
LINK
The root directory name can be changed by modifying the "Name" property for the DIRECTORY element.
I implement wix to generate some msi. I'd like to maintain .bat file (that is packed within this wix project) to contain some work to do (and to be activated with some custom action)
I added the .bet to my wix project in VS2010.
My question is
how do I actually wrap it within the msi that on target machine the script will be available to run?
How do I actually refer to that embedded batch file in the custom section element
This might not be the answer you're looking for, but I strongly recommend you NOT going this way. Running batch file from inside the MSI package has a number of disadvantages, which will shoot you one day:
antivirus might block the execution
as for any deferred custom action (the one which changes the target system state) you'll have to create a rollback action, and for a batch file which might include a number of steps of different nature it could be much more difficult
you don't have the progress (I doubt this is at all possible for batch script)
Instead, I encourage you to do the following:
analyze your batch script and make a list of exact things it does to the target system
take a look at the standard Windows Installer functionality and WiX extensions to see what's there out of the box
design your installation to use standard functionality as much as possible and custom actions as little as possible
if you still need a custom action, stick to the DLL ones and make sure rollback actions are present for deferred actions
You're looking for what I think is a type 18 custom action:
The executable is generated from a file installed with the application. The
Source field of the CustomAction table contains a key to the File table. The
location of the custom action code is determined by the resolution of the target
path for this file; therefore this custom action must be called after the file
has been installed and before it is removed.
The CustomAction element has the ExeCommand attribute for just this sort of occasion. It would look something like this:
<CustomAction Id="ExecuteMyBatchFile"
FileKey="[#FileKey]"
ExeCommand="Arguments passed to batch file"
Execute="deferred"/>
Of course, this is assuming the batch file is installed by the msi.