I'm converting our current monolithic installer to use a WiX 3.7 Bundle/chain. We have several components that are now building into their own separately-maintainable MSI installers. My next task is to add all of these to a bootloader/bootchainer, but I've hit a snag.
A requirement for our individual installers is that they contain the version in the filename (i.e. MyApplication-5.4.22.msi). I don't see a tool like Heat for collecting MSI packages together, and I don't see a way to add an MsiPackage element with a wildcard to account for varying package names.
As a last resort, I can wrap the bundler inside of another MSBuild script that will 'autocomplete' the filenames and pass the paths in as variables to the bundler. I'm hoping someone can recommend a solution that works directly in the wxs or wixproj setting.
If the msi files are built with WiX Setup projects, the WiX Bootstrapper project can reference them, thereby creating useful WiX variables that are defined as the paths to the msi files.
See my answer here, as well as the list of variables here.
If that's not the case then you can write some MSBuild targets that run before the Build target to figure out the actual file paths. If the available standard and community MSBuild tasks aren't sufficient, you can write your own tasks, either by creating an assembly or using inline code. (And, of course, there is always the Exec task to shell out to a command-line program like cmd.exe, after which you can parse its output to extract the msi paths.)
Related
Is it possible to make a WiX installation bundle with size of total .msi's and exe's inside bundle more than 2GB? Currently in my .wxs template I have a <chain> inside of a <bundle> that contains multiple <MsiPackage>'es. I haven't created that WiX template on my own, I'm just improving/fixing bugs in a legacy project, so I am not very proficient with the WiX toolset. Anyway, then I create a .wixobj out of that .wxs template with candle.exe and this .wixobj I feed to light.exe. It seems that if total size of content to link is more than 2GB light.exe fails with error:
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.
I looked for solution and one suggestion was to use <MediaElement> but that one is only available in a <product> tag which I guess I cannot use in my situation, because the bundle that I am cooking has a custom bootstrapper embedded, and as far as I understood wix product template is not about bootstrapper applications. Another opinion that I found was that you can't create WiX bundle with size of single package more than 2GBs, but that is not exactly my case, because each package I am bundling is no more than 700MBs.
I have already tried separating <MsiPackage>s into <PackageGroup>'s in separate <Fragment>'s which was referenced in <Bundle>'s <chain> in <PackageGroupRef>, but it didn't help, light.exe throws the same error. I have also found a suggestion to try to put packages into separate <Container>s in <bundle>, but I didn't manage to try it because I didn't understand how to do it, WiX bundle documentation just mentions that the are some containers but never actually gave an advice on how to use them.
I am using WiX 3.11
UPD: I just wanted to add some clarifications.
My goal is to make a bundle what would be a single .exe file with all related .cab's and other stuff embedded into the final bundle, so delivering bundle that consist of .exe bootstrapper and multiple external .cab file isn't really a preferred option even though it might be x times faster unless this is the only solution in my case.
UPD 2:
It seems that yet you can assemble a bundle with 2 GBs + size, it won't start. Maybe because the output executable is x86, and windows can't launch x86 executables over 2gbs size. I didn't manage to make an x64 bundle, maybe that would work, but I never found how to do it. Guess the only option is to let users download missing content and make bundle only contain essential parts. Thanks everyone for help.
Compressed bundles cannot be bigger than 2GB. Burn supports containers up to 2GB each and only one container can be attached to the bundle .exe itself.
Bob's answer is still correct for v3.
Support for multiple attached containers was recently added in v4 (#6144). That allows a single file bundle to be larger than 2GB. v4 also added support for x64 (and ARM64) bundles, which allows the bundle to be larger than the x86 maximum.
A related open feature request is #6521 where WiX would automatically split payloads across containers so that the user doesn't have to manually create new containers to avoid the cabinet limitations for size or number of files.
I would like to create a setup project based on WiX which does the following (as well as creating the installation package):
callable from msbuild running on a CI build server (Hudson)
take a version number from some asset in either the setup project or the main assembly
take the current build number from the CI system
create a full product version number [version].[build] such as 1.3.432
store this value in an asset (e.g. the main assembly) is such a way that it can be read out at run time and displayed on the splash window
I have tried a number of approaches and googled a lot but have not found a workable solution. Can anyone help?
The WiX toolset does this by creating a version.cs, a version.h and a version.wxi during the MSBuild then including those files in all the projects. That way our executable can print out their version when you run something like candle.exe -? and all of the bundles and .msi packages have their versions set correctly.
You can see how we do this in tools\WixBuild.Version.targets (here). It would straight forward to override the properties in WixBuild.Version.targets with properties passed via the command-line to MSBuild via Hudson if you wanted.
I’m writing an MSI for using WiX 3.0 and I’m trying to figure out how to make it include all but some files from a directory without having to manually specify each and every attribute. Similar to a dynamic pickup in installshield.
An old installer I’m looking at for reference (which uses WiX 2.0) does the following:
A makefile to call a script that will copy all the necessary files to a separate directory structure that emulates how the final product should be installed.
another script to insert the attributes for each of the files in this temp folder to a partially completed wxs file.
WiX runs
I want to avoid this step and was wondering if there were some commands or pre-processor directives to achieve this WiX itself?
Also the 1st step above spits out some generated files (from a tool) which is then included into the wxs file. Is there a way I can emulate that as well?
You need to specify each file.
However, you can use Heat.exe to automatically generate a wxs file you can include as part of your build process.
I cheaped out with a non-solution, and zipped up the directory and it's files in the build script. The advantage of your current method is that MSI is aware of the files and they could potentially be key files (and thus patched/upgraded and/or repaired).
I'd look into saschabeaumont's suggestion about using heat. clearly a better solution
I've just started looking at wix again now that it looks like installer projects are going to be deprecated from VisualStudio. We have a third party application that is "install via xcopy", which makes it hard for us to track in terms of versioning so we'd like to create an msi for it. There are several hundred files that are part of the installation.
I'd like to use heat to create the list of files for the installer, but I've heard that it's not good to use heat to create the wxs file more than once with autoguids because then your installer will have issues.
I was wondering if in wix 3.6, there was a command line parameter to heat which would take a previously generated wxs file as the source for guids? I want heat to autogenerate guids for any new files, but use the previous output of heat as a database for existing files.
If you use the -ag flag this will set the guids to be generated at compile time and as long as the path doesn't change the compiler will keep the same guid for each component. Rather than use a command-line to do the harvesting it is better to edit the *.wixproj file and add a HeatDirectory element.
I've got a legacy project where they had a bunch of visual studio setup projects to create installation packages of the same plugin for different versions of a 3rd party application.
I'm trying to figure out how to build the setup projects so that they work.
Extracting the contents of a previously compiled MSI and the one I get when building the project the assemblies in the Global Assembly Cache folder inside my MSI and the other one are different. The other MSI has a suffix appended to the names of the assemblies.
As a part of the compilation process of the MSIs they apparently had a script renaming assemblies in the compiled MSI packages using the The SQL query strings for Windows Installer.
I have the script and running it against my MSI does not rename the assembly files as looked at when I extract the contents of the MSI.
The SQL statements which I suppose should rename the assemblies are of the following form:
update MsiAssemblyName set Value = 'AssemblyNameSuffix' where Value = 'AssemblyName'
Running the script does change the MSI in some way but I don't see the assembly files renamed.
The question is if it is possible to rename the assembly files in an MSI with SQL this way and if so how can this be achieved?
Thanks!
No, it's not possible. Even if you updated the File table to have the new file name, the assembly would be broken because .NET Assemblies have metadata in them that describe their assembly name, namespace and classes. Renaming a file will break it.