I'm deploying two CDs, and thinking both will have a setup.exe bundle.
One CD will be called "standard SKU" and setup.exe will install a.msi, and b.msi.
The other CD will be called "pro SKU" and setup.exe will install a.msi, b.msi, and c.msi.
What is the proper procedure when authoring the setup.exe files? Specifically, for the scenario where somebody installed the standard SKU, and then installed the pro SKU on top; would this be considered a related bundle/upgrade? Just install both bundles and keep both entries in ARP? Something else?
I wouldn't try to use upgrades here but related bundles is definitely the place to start. In this case, I would have the two Bundles share a RelatedBundle id and Tag them appropriately. Add something like the following to the "standard" Bundle:
<Bundle ... Tag='standard'>
<RelatedBundle Id='PUT-SAME-GUID-HERE' Action='Detect' />
Do the same for the "pro" Bundle but Tag it appropriately.
Now, in your custom bootstrapper application, on the OnDetectRelatedBundle() you'll get a callback when if one of the Bundles is already installed. That callback will also send back the Tag so you'll know which Bundle was present. You can display the result to the user or whatever if you like. The real important part is that during the OnPlanRelatedBundle() callback, you'll want to return the appropriate RequestState to say whether to remove or leave the found Bundle.
Good luck, all the data is there, just a matter of getting the right callbacks.
Related
We have 2 installer sources in WiX to create installer for a single product with same Product Version, GUID and Package GUID also.
Those 2 installer projects will yield different outputs, one output being just a single MSI file (File1.msi) and other project output is a CD-ROM structure having different MSI file name (File2.msi).
So now issue arises when we installed the product using single MSI file, upon that if we invoke MSI from the other CD-ROM output, we end up getting below mentioned error.
I tried keeping same MSI filename for both kind of installer output, then this above error dialog was resolved but repair functionality isn't working.
If some files were deleted in the product's destination folder, it says source file not found error pointing to CD-ROM installer source folder.
Please help where I'm going wrong. I want to support Repair installation without this errors.
The dialog is expected. You can't change the name of the MSI except during major upgrades.
After that, if you rebuilt to create the different layouts, each MSI probably has a unique PackageCode and that makes them unique packages. That is most likely why repair isn't working. A verbose log file should tell all.
Updated: Compile your main MSI, then run administrative image on it and put the extracted files and MSI on the CD? Put the compressed
version on there as well - just in case they prefer that kind of
release (happens).
I am not sure what will happen when you run both setups this way, but
I think the MSI flagged as an administrative image extract might be
detected by the engine. I am not sure. Should work. Built-in approach for MSI, and you are not fighting wind-mills.
User Accounts: Are you creating any NT User Accounts? Did you set the FailIfExists attribute to yes? Please check here:
User Element (Util Extension). What is the setting for UpdateIfExists? (if any).
Other Issues: There might be other issues as well as Rob mentions. You can not use the same package code for both release types because a package code by definition identifies a unique file. All kinds of X-Files-like problems occur if you try to "hack" this. Not a fight you want to take on.
Administrative Installation: Why would you want to distribute different setups on CDs these days? Corporations that use your setup will run an administrative installation on your setup extracting all files - which is a much better concept. It is essentially a glorified file-extraction, and it is a built in Windows Installer concept intended to make a network installation point for software - among other things. It essentially extracts all files and translates the Media table to use external source files.
List of Links:
What is the purpose of administrative installation initiated using msiexec /a?
Extract MSI from EXE
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 have an application with a bootstrapper that installs multiple components below it. The code below uses ninject to have a loosely coupled database layer.
With regards to the bundle/bootstrapper, I would like to move the database layer out into a separate msi in order to support optional data layer choices on install (e.g.: radio buttons to install SQLite/SQLExpress/MySQL etc..).
I am struggling to figure out how to get the install directory working though, as the database components needs to install into the root/install directory of the main application. (rather than using the gac etc).
How can I do this? I have tried the steps mentioned here: How to use properties to set the installation path? but to no avail. I must have something wrong.. but given the code is spread over 5(ish) files, it seems a little large to load here!
Any pointers to get started trying to implement this, or should I go ahead and upload the code?
The method you refer to should work. Note however that the name of the property given in
<MsiProperty Name="INSTALLLOCATION"
should match the name used in wxs file of the corresponding MSI package. Typically if the MSI was created based on WixUI_InstallDir template the name would be APPLICATIONFOLDER and in the default template without the UI it is INSTALLFOLDER.
I'm using a bootstrapper to check for the existence and if needed install a set of 3rd party product installs. It then installs my product. I would like to include an uninstall shortcut for the full install and not just my product. However, to do that, I need to be able to set the product code for the bootstrapper and then reference it in my uninstall shortcut:
<ShortcutId="UninstallShortcut" Name="Uninstall My Product"
Description="Uninstalls My Product"Target="[System64Folder]msiexec.exe"
Arguments="/x [MyBootStrapperProductCode]" Icon="MainApp.ico"/>
I'm using the standard Wix bootstrapper, but I don't see anything within the Bundle element that will let me set the product code.
Alternately, can I prevent the bootstrapper from leaving references to itself in Add/Remove Programs? The 3rd party components are permanent deployments.
The Bundle doesn't work the same way as Product. It does not use msiexec to unistall, atleast not publicly.
In order to create UNISTALL shortcut for BUNDLE, you need some clever tricks. Disclaimer: only for developmental/internal use.
First; you need to pass UpgradeCode to your MSI, using this approach:
Passing command line args to MSI from WiX bundle
After that, in your MSI file, you could try searching registry value BundleUpgradeCode which equals to your UpgradeCode. If you have found the folder where value lies, you can extract UnistallString and execute it directly(using CustomAction).
It will be something like this: "C:\ProgramData\Package Cache{my GUID}\ExchangeBootStrapper.exe" /uninstall
I personally haven't implemented it yet, but couldn't find any other workaround for this problem and came up with this one.
I am late, but at least for the record. As I understand the products in the Chain of Burn are handled independently. So the uninstalls does. It means that you don't need the code for the whole bundle. Codes of the individual Msi files in the bundle chain will be used for the un-installation. As for permanent installation of 3d parties there is corresponding Permanent attribute. This all is quite well described in last two chapters of WiX 3.6 Guide by Ramirez N.
Looking for a way out of the corner my company has painted itself into.
Windows Services are currently installed by manually copying files around and running various batch files to install / uninstall. Locations differ by site and depending on whether the installed code is for production or test usage. So my debug build might need to install into
C:\someFolder\Site1\Test
while the Release build of the same code would install into
C:\someFolder\Site1
Currently only 2 sites but probably expanding soon.
I'm trying to put together a WiX install project (VS2010, WiX 3.5) to handle the installation. I'm not able to change the install folder definition (much as I would like to!) and I'm running into problems trying to understand how I might approach the problem. Being a newbie to WiX doesn't help.
For the question about release/debug versions:
At the place in your code where you are defining your target directory, you can conditionally set it based on the build version. For example, Debug is an available variable that can be used like:
<!-- inside of somefolder/site target definition, conditionally append test dir -->
<?ifdef var.Debug ?>
<Directory Id="TestId" Name="test" />
<?endif?>
You can also add other build dependent variables in visual studio for each type of release. This would be a unique build for each target situation model. This could easily get confusing to users about which version they should use.
The other model - one build with flexible target locations:
For the different site directories: Depends on how those sites are created.
If they exist previous to your install, just use wix's directorysearch to set a property used to build the target directory.
If instead the target directory is decided at install time, and its based on user's decision, then you'll need to prompt for the name or type (site). This will be similar to the typical situation of asking for a custom install directory. You can modify one of the sample custom wix dialogs included in the wix source that do this and add that dialog to your project's next/back flow.