I create my instalator Wix with msi and bootstrapper.
I am do test for update my program. And trying install new version. I want always use bootstrapper. I don't know if this was always the case, but I did some tweaks and added a progress bar to the bootstrapper for MSI installations. And it turns out that when updating, this bar stops at 60/70% and after closing MSI a new bootstrapper window appears. Closing the window a few times causes the progress bar in the first window jump to 100% and I can close the window.
I dont have idea why it happen.
I check logs and in both cases last line looks like:
Applying execute package: Installer, action: Install, path: C:\ProgramData\Package Cache{9428A5CF-824D-42D0-ABF7-BC69D4B8FEE7}v1.0.26.40\EkInstaller.Elements.msi, arguments: ' MSIFASTINSTALL="7" CONFIGFILELOCATION="C:\svn\122\dotNet\products\3_ek-graf-pre-v2\trunk\src\Ek.Installer\Ek.Installer.Bootstrapper\bin\Debug"'
And besides this lines I dont show differents in logs:
[4EDC:2970][2020-07-23T08:54:34]i102: Detected related bundle:
{2e954545-621e-4062-a306-99197563c483}, type: Upgrade, scope:
PerMachine, version: 1.0.24.39, operation: MajorUpgrade
[4EDC:2970][2020-07-23T08:54:34]i102: Detected related bundle:
{770a1869-f4b5-4307-b05f-1f8be006757b}, type: Upgrade, scope:
PerMachine, version: 1.0.23.39, operation: MajorUpgrade
[4EDC:2970][2020-07-23T08:54:34]i102: Detected related bundle:
{ff8d8a34-989d-4fb9-9aa7-2ab0440f514d}, type: Upgrade, scope:
PerMachine, version: 1.0.25.39, operation: MajorUpgrade
[4EDC:2970][2020-07-23T08:54:34]i103: Detected related package:
{D512899C-F7CC-412C-9110-54CDE5BB2741}, scope: PerMachine, version:
1.0.25.40, language: 0 operation: MajorUpgrade
Probably first three are for NetFramework, Sql and SSMS which install bootstrapper and last is for my MSI.
I was trying change InstallerVersion in Package and Schedule in MajorUpgrade.
The installer is very complex, I can't make all the code available. Maybe someone knows the reasons for this behavior and can direct me to why it is.
Noticed when MSI progress bar status = "Delete Files" in then progress bar bootstrapper stop.
Edit:
It spawn additional window bootstrapper for event previous version bootstrapper.
If i dont change version bootstrapper it dont spawn dialog and it goes to 100% normally when updating msi.
Seems to be a wix bug. For each subsequent bootstrapper version installed, new bootstrapper windows appear when the MSI window is closed. You can fix it by following through change UpgradeCode for each new version Bundle. If you additionally set DisableModify = "yes" DisableRemove = "yes" then there will be no additional bootstrapper instances in add / remove program.
Related
Users of our managed bootstrapper installer should be able to downgrade the bundle in case a new version causes problems:
<MajorUpgrade Schedule="afterInstallValidate" AllowDowngrades="yes" AllowSameVersionUpgrades="no" />
When upgrading, the existing bundle is properly uninstalled. Only the new version remains in the list of installed programs in Programs and Features. The log confirms the chosen action:
OnDetectRelatedBundle(): Operation MajorUpgrade
OnDetectRelatedBundle(): RelationType Upgrade
Planned package: APP_MSI_PACKAGE, state: Absent, default requested: Present, ba requested: Present, execute: Install, …
Planned related bundle: { }, type: Upgrade, … execute: Uninstall, rollback: Install, dependency: None
When downgrading, the existing bundle remains in Programs and Features. According to the log, the type downgrade is recognized, but no Uninstall is planned:
OnDetectRelatedBundle(): Operation Downgrade
OnDetectRelatedBundle(): RelationType Upgrade
Planned package: APP_MSI_PACKAGE, state: Obsolete, default requested: None, ba requested: None, execute: None, …
Planned related bundle: {}, type: Upgrade … execute: None, rollback: None, dependency: None
There shouldn't be two entries for the same application in Programs and Features. After the downgrade I can uninstall the obsolete version manually, but the user should not have to do that.
I find it confusing that MajorUpgrade is part of <Product>, but then in Programs and Features the version is tracked for the entire bundle. I read somewhere that the same UpgradeCode should be used in Product and Bundle. Is that recommended? I tried the same UpgradeCode and separate UpgradeCodes. There seems to be no difference.
I’ve researched a bit and supposedly the uninstallation is not supported when downgrading. Is that true?
If it is not supported, how can I trigger the uninstallation of the related bundle manually from the managed bootstrapper code?
Truly, the problem boils down to the double entry in Programs and Features. If I cannot uninstall it, can I remove (or maybe hide, which I would consider a terrible hack) the obsolete version of the bundle via code some other way?
I had to determine if the setup installs a downgrade by using the event DetectRelatedBundle. Then in the event handler for PlanRelatedBundle I had to specify that the related bundle should be absent:
private void OnPlanRelatedBundle(object sender, PlanRelatedBundleEventArgs e)
{
if (BundleUpgrade || BundleDowngrade)
e.State = RequestState.Absent;
}
For good measure I set the absent state when an upgrade was detected as well even though that case already worked. Now the related bundle is removed in both cases.
I've upgraded an old Wix based installer that has both an MSI generating project and a bootstrapper project (in Visual Studio). The bootstrapper sequences the MSI with a check for .Net pre-requisite/download. The new Wix# project just produces an MSI and it is installing and working just fine other than I cannot get it to replace the older installs. I've set the new project UpgradeCode to match what I see in the old MSI project (and which is in the windows registry in the uninstall list). I see the UpgradeCode being generated into the WXF file. But when I couldn't get that to work I tried setting it to match the UpgradeCode from the self-installing bootstrapper (which is what the end user runs). That didn't help.
I've read about similar experiences here and here. I've also set the upgrade strategy a few different ways including:
project.MajorUpgrade = MajorUpgrade.Default;
And:
project.MajorUpgrade = new MajorUpgrade
{
Schedule = UpgradeSchedule.afterInstallInitialize,
AllowDowngrades = true,
IgnoreRemoveFailure = true,
AllowSameVersionUpgrades = false
};
And:
project.MajorUpgradeStrategy = new MajorUpgradeStrategy
{
RemoveExistingProductAfter = Step.InstallInitialize,
UpgradeVersions = new VersionRange
{
Maximum = project.Version.ToString(),
IncludeMaximum = false,
MigrateFeatures = false
},
PreventDowngradingVersions = new VersionRange
{
Minimum = project.Version.ToString(),
IncludeMinimum = false
},
NewerProductInstalledErrorMessage = "A newer version of [ProductName] is already installed. Setup will now exit."
};
And various variations on those themes. Nothing I've done has impacted behavior, which is to say after installing, both the old and the new version of the application is listed in the add/remove Windows list. Is there some missing secret sauce to this migration path?
UPDATE:
I've realized my last snippet attempt there is actually working*. It's triggering the removal of everything except the entry in the Windows add/remove programs! Can this be due to a name change for the application in the new installer? Or maybe it's remaining around due to the old bootstrapper somehow, since I'm using the UpgradeCode from the old MSI and not doing anything specific with the bootstrapper?
UPDATE2:
The "old" installer has both an MSI and EXE (bootstrapper) version of the setup. If I just install using the old MSI, then run the new MSI, all works perfectly. So it seems that it is something related to running the bootstrapper EXE that is not getting removed.
My frustration level is nearing 10. I've been working on a wix installer for a couple weeks now. This installer installs prerequisites for our software. I don't have Visual Studio so I made a batch file to build (read command line only) the wix project. There are about 9 prerequisites which include .msi, .msu, and .exe files in this bundle.
My question relates specifically to the ExePackage described in the chain element. It seems several (but not all) ExePackages always install regardless of the DetectCondition, InstallCondition, on Install, and on Unistall. The log file shows the DetectCondition = true and the InstallCondition = false but these problem ExePackages still execute and install. Every. Time.
I read somewhere on stackoverflow in the past two weeks of frustration, that ExePackages don't allow the same visibility by the installer as .msi files and that can cause problems with exactly what I'm dealing with. I seem to remember someone mentioning how, on uninstall, the ExePackage gets executed and if the actual .exe file doesn't have the proper internal flags, it will install instead of uninstall. However, if I remember correctly, although those answers were good for their questions, I haven't been able to find something that completely prevents the execution of the ExePackage under certain conditions.
EDIT 1: I'm using WiX Version 3.7.
I'd like an example or some lifeline giving me a clue about how to do this. Here's an example of a problem ExePacakge:
...
<Bundle Name='MySoftware' Version='1.0.0.0' Manufacturer='MyCompany'
UpgradeCode='{GUID}'
Condition='(VersionNT >= v6.1 AND ServicePackLevel >= 1)'>
...
<util:FileSearch Id='CheckChromeVersion' Path='[ProgramFilesFolder]Google\Chrome\Application\chrome.exe' Variable='CHROMEVERSION' Result='version' />
<util:FileSearch Id='CheckChromeExists' Path='[ProgramFilesFolder]Google\Chrome\Application\chrome.exe' Variable='CHROMEEXISTS' Result='exists' />
...
<Chain>
...
<ExePackage Id='Chrome'
Compressed='yes'
SourceFile='.\installers\ChromeStandaloneSetup64-v51.0.2704.103.exe'
PerMachine='yes'
DetectCondition='CHROMEEXISTS AND CHROMEVERSION="51.0.2704.103"'
InstallCondition='(NOT CHROMEEXISTS) OR (NOT CHROMEVERSION="51.0.2704.103")' />
...
</Chain>
</Bundle>
...
And here are all instances of 'chrome' from the log file:
[0910:0794][2017-09-20T06:30:33]i000: Setting numeric variable 'CHROMEEXISTS' to value 1
[0910:0794][2017-09-20T06:30:33]i000: Setting version variable 'CHROMEVERSION' to value '51.0.2704.103'
[0910:0794][2017-09-20T06:30:33]i052: Condition 'CHROMEEXISTS AND CHROMEVERSION="51.0.2704.103"' evaluates to true.
[0910:0794][2017-09-20T06:30:33]i101: Detected package: Chrome, state: Present, cached: None
[0910:0794][2017-09-20T06:30:34]i052: Condition '(NOT CHROMEEXISTS) OR (NOT CHROMEVERSION="51.0.2704.103")' evaluates to false.
[0910:0794][2017-09-20T06:30:34]w321: Skipping dependency registration on package with no dependency providers: Chrome
[0910:0794][2017-09-20T06:30:34]i000: Setting string variable 'WixBundleLog_Chrome' to value 'C:\Users\User\AppData\Local\Temp\MyProgram_20170920063033_2_Chrome.log'
[0910:0794][2017-09-20T06:30:34]i000: Setting string variable 'WixBundleRollbackLog_Chrome' to value 'C:\Users\User\AppData\Local\Temp\MyProgram_20170920063033_2_Chrome_rollback.log'
[0910:0794][2017-09-20T06:30:34]i201: Planned package: Chrome, state: Present, default requested: Absent, ba requested: Absent, execute: Uninstall, rollback: Install, cache: Yes, uncache: Yes, dependency: None
[01B4:0E6C][2017-09-20T06:30:54]i305: Verified acquired payload: Chrome at path: C:\ProgramData\Package Cache\.unverified\Chrome, moving to: C:\ProgramData\Package Cache\9102865AE2381BC34E91C107DA5818CF971356E8\ChromeStandaloneSetup64-v51.0.2704.103.exe.
[01B4:0F1C][2017-09-20T06:31:19]i301: Applying execute package: Chrome, action: Uninstall, path: C:\ProgramData\Package Cache\9102865AE2381BC34E91C107DA5818CF971356E8\ChromeStandaloneSetup64-v51.0.2704.103.exe, arguments: '"C:\ProgramData\Package Cache\9102865AE2381BC34E91C107DA5818CF971356E8\ChromeStandaloneSetup64-v51.0.2704.103.exe"'
[0910:0794][2017-09-20T06:31:33]i319: Applied execute package: Chrome, result: 0x0, restart: None
[01B4:0F1C][2017-09-20T06:31:59]i351: Removing cached package: Chrome, from path: C:\ProgramData\Package Cache\9102865AE2381BC34E91C107DA5818CF971356E8\
[0910:0794][2017-09-20T06:32:02]i410: Variable: CHROMEEXISTS = 1
[0910:0794][2017-09-20T06:32:02]i410: Variable: CHROMEVERSION = 51.0.2704.103
[0910:0794][2017-09-20T06:32:02]i410: Variable: WixBundleLog_Chrome = C:\Users\User\AppData\Local\Temp\MyProgram_20170920063033_2_Chrome.log
[0910:0794][2017-09-20T06:32:02]i410: Variable: WixBundleRollbackLog_Chrome = C:\Users\User\AppData\Local\Temp\MyProgram_20170920063033_2_Chrome_rollback.log
Thanks in advance for your help.
The issue is being caused by the InstallCondition on your ExePackage
A condition to evaluate before installing the package. The package will only be installed if the condition evaluates to true. If the condition evaluates to false and the bundle is being installed, repaired, or modified, the package will be uninstalled.
In your logs you can see that the DetectCondition is properly being evaluated as "True" so the bundle does detect the right version of Chrome is installed.
However the InstallCondition is being evaluated to false
[0910:0794][2017-09-20T06:30:34]i052: Condition '(NOT CHROMEEXISTS) OR (NOT CHROMEVERSION="51.0.2704.103")' evaluates to false.
This causes this plan line to show up
[0910:0794][2017-09-20T06:30:34]i201: Planned package: Chrome, state: Present, default requested: Absent, ba requested: Absent, execute: Uninstall, rollback: Install, cache: Yes, uncache: Yes, dependency: None
The install condition I think is supposed to be used in cases where you can selectively install things based on what is already on the system or what was selected to be installed during the UI portion of the bootstrapper. ie: you can use this ExePackage if another program is already present otherwise don't install it (and uninstall it if that other program is no longer present). You would then use the install condition in this case but normally it is not useful to define the install condition.
The old answer below does not apply to the question but it can still be useful to someone with version comparison conditions so I'll leave it
Version comparison in a condition should be
CHROMEVERSION gt;= v51.0.2704.103
The v infront of the version tells wix to evaluate the condition as two version variables. All RegistrySearch variables are String variables and the comparison between the variables in your condition gets evaluated based on the format of the variables themselves. Since the registry search is always a string, the other operand in the expression determines what type of comparison happens.
I've recently included a bootstrapper into my solution, and I've noticed that after testing a variety of free Anti-Virus programs, both Avast and AVG seem to now cause my installation to fail, has anyone else experienced this?
My current thought is that the cause of the install failing is the CyberCapture feature in both of these products, which causes a delay in the install due to
the Anti-Virus performing a 'quick'(15 or so seconds) scan of the files in the .exe multiple times - when first starting up, and then when clicking install. Could this possibly be something to do with the v3.10.2 security release to resolve the potential DLL hijacking issue?
My installer is signed properly (using insignia and signtool), but a few of the .exes and .dlls that are in the project aren't, could this also be causing it? It seems to be related to a routine scan rather than a potential threat being blocked.
Any insight into why this is happening and/or how this can be resolved would be much appreciated! I'm using WiX v3.11, and the burn chain is comprised of an exe package and an msi package. Thanks.
Attached is the install log for any additional info.
[1DF0:1DFC][2017-06-06T11:03:22]i001: Burn v3.11.0.1528, Windows v10.0 (Build 10240: Service Pack 0), path: C:\Users\NC01\AppData\Local\Temp\{53A054CB-02F6-47A4-85AF-50ABF1DDFDAF}\.cr\proj.exe
[1DF0:1DFC][2017-06-06T11:03:22]i000: Initializing numeric variable 'ACCEPTEULA' to value '0'
[1DF0:1DFC][2017-06-06T11:03:22]i009: Command Line: '-burn.clean.room=C:\Users\NC01\Desktop\proj.exe -burn.filehandle.attached=392 -burn.filehandle.self=404 -log C:\Users\NC01\Desktop\installLog.log'
[1DF0:1DFC][2017-06-06T11:03:22]i000: Setting string variable 'WixBundleOriginalSource' to value 'C:\Users\NC01\Desktop\proj.exe'
[1DF0:1DFC][2017-06-06T11:03:22]i000: Setting string variable 'WixBundleOriginalSourceFolder' to value 'C:\Users\NC01\Desktop\'
[1DF0:1DFC][2017-06-06T11:03:22]i000: Setting string variable 'WixBundleLog' to value 'C:\Users\NC01\Desktop\installLog.log'
[1DF0:1884][2017-06-06T11:03:22]e000: Error 0x80070057: Failed to load splash screen bitmap.
[1DF0:1884][2017-06-06T11:03:22]e000: Error 0x80070057: Failed to load splash screen.
[1DF0:1DFC][2017-06-06T11:03:22]i000: Setting string variable 'WixBundleName' to value 'ProjectName'
[1DF0:1DFC][2017-06-06T11:03:22]i000: Setting string variable 'WixBundleManufacturer' to value 'CompanyName'
[1DF0:0764][2017-06-06T11:03:22]i000: Setting numeric variable 'WixStdBALanguageId' to value 1033
[1DF0:0764][2017-06-06T11:03:22]i000: Setting version variable 'WixBundleFileVersion' to value '4.0.0.632'
[1DF0:1DFC][2017-06-06T11:03:22]i100: Detect begin, 2 packages
[1DF0:1DFC][2017-06-06T11:03:22]i101: Detected package: CleanupToolExe, state: Absent, cached: None
[1DF0:1DFC][2017-06-06T11:03:22]i101: Detected package: projMsi, state: Absent, cached: None
[1DF0:1DFC][2017-06-06T11:03:22]i199: Detect complete, result: 0x0
[1DF0:0764][2017-06-06T11:03:24]i000: Setting numeric variable 'EulaAcceptCheckbox' to value 0
[1DF0:1DFC][2017-06-06T11:03:24]i200: Plan begin, 2 packages, action: Install
[1DF0:1DFC][2017-06-06T11:03:24]w321: Skipping dependency registration on package with no dependency providers: CleanupToolExe
[1DF0:1DFC][2017-06-06T11:03:24]i000: Setting string variable 'WixBundleLog_CleanupToolExe' to value 'C:\Users\NC01\Desktop\installLog_000_CleanupToolExe.log'
[1DF0:1DFC][2017-06-06T11:03:24]i000: Setting string variable 'WixBundleRollbackLog_CleanupToolExe' to value 'C:\Users\NC01\Desktop\installLog_000_CleanupToolExe_rollback.log'
[1DF0:1DFC][2017-06-06T11:03:24]i000: Setting string variable 'WixBundleRollbackLog_projMsi' to value 'C:\Users\NC01\Desktop\installLog_001_projMsi_rollback.log'
[1DF0:1DFC][2017-06-06T11:03:24]i000: Setting string variable 'WixBundleLog_projMsi' to value 'C:\Users\NC01\Desktop\installLog_001_projMsi.log'
[1DF0:1DFC][2017-06-06T11:03:24]i201: Planned package: CleanupToolExe, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: Yes, uncache: No, dependency: None
[1DF0:1DFC][2017-06-06T11:03:24]i201: Planned package: projMsi, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: Yes, uncache: No, dependency: Register
[1DF0:1DFC][2017-06-06T11:03:24]i299: Plan complete, result: 0x0
[1DF0:1DFC][2017-06-06T11:03:24]i300: Apply begin
[1DF0:1DFC][2017-06-06T11:03:24]i010: Launching elevated engine process.
[1DF0:1DFC][2017-06-06T11:03:53]i011: Launched elevated engine process.
[1DF0:1DFC][2017-06-06T11:03:53]e000: Error 0x800700e8: Failed to wait for child to connect to pipe.
[1DF0:1DFC][2017-06-06T11:03:53]e000: Error 0x800700e8: Failed to connect to elevated child process.
[1DF0:1DFC][2017-06-06T11:03:53]e000: Error 0x800700e8: Failed to actually elevate.
[1DF0:1DFC][2017-06-06T11:03:53]e000: Error 0x800700e8: Failed to elevate.
[1DF0:1DFC][2017-06-06T11:03:53]i399: Apply complete, result: 0x800700e8, restart: None, ba requested restart: No
[1DF0:1DFC][2017-06-06T11:27:14]i500: Shutting down, exit code: 0xe8
Update: Unfortunately the only solution here seems to be submitting a fully signed (including insignia) build to be added to the Avast! and AVG whitelist, and then waiting until it has been added in an update.
I have the same issue here, Avast CyberSecurity and Deepscan both block our burn executable. I signed the exe, the engine, used insignia with an official code signing cert. The MSI is signed and the application executable is signed.
Without burn the MSI runs fine tho. It is the most simple burn template, perhaps a custom BA will work different. Else I just might write an own executable around the MSI :)
We recently switched over to a custom bootstrapper for our installer. This allows the user to select from a list of possible modules to install (each as separate msi's). We are now making our first upgrade and have run into an issue. Burn properly upgrades the msi's but it's not properly dealing with the bootstrapper which is listed in the ARP. It attempts to uninstall the bootstrapper last but then fails because a higher version of the bootstrapper has already been installed.
According to this article https://support.firegiant.com/entries/24024208-Bundle-chain-execution-order- the execution order for an upgrade should have the related bundle uninstalled first:
"When planning an uninstall, the Burn engine plans all related bundles first. Thus related bundles are always removed before the chained packages are removed.
However, that's not the behavior we're seeing. The related bundle is uninstalled last:
[11C4:0868][2015-02-26T10:09:26]i102: Detected related bundle: {9e3abad2-c78b-48ec-a523-c5c4de4fe3f1}, type: Upgrade, scope: PerMachine, version: 7.5.0.0, operation: MajorUpgrade
...
[11C4:0868][2015-02-26T10:09:38]i207: Planned related bundle: {9e3abad2-c78b-48ec-a523-c5c4de4fe3f1}, type: Upgrade, default requested: Absent, ba requested: Absent, execute: Uninstall, rollback: Install, dependency: None
[11C4:0868][2015-02-26T10:09:38]i299: Plan complete, result: 0x0
...
[1224:0E20][2015-02-26T10:23:26]i301: Applying execute package: {9e3abad2-c78b-48ec-a523-c5c4de4fe3f1}, action: Uninstall, path: C:\ProgramData\Package Cache\{9e3abad2-c78b-48ec-a523-c5c4de4fe3f1}\FlexSimInstaller.exe, arguments: '"C:\ProgramData\Package Cache\{9e3abad2-c78b-48ec-a523-c5c4de4fe3f1}\FlexSimInstaller.exe" -uninstall -quiet -burn.related.upgrade -burn.ancestors={36ff969e-da98-4c27-9dde-20e090c0812f}'
[11C4:0868][2015-02-26T10:23:35]i319: Applied execute package: {9e3abad2-c78b-48ec-a523-c5c4de4fe3f1}, result: 0x0, restart: None
[11C4:0868][2015-02-26T10:23:35]i399: Apply complete, result: 0x0, restart: None, ba requested restart: No
[11C4:0868][2015-02-26T10:23:38]i500: Shutting down, exit code: 0x0
We know there is no way to change the order, so how do we get the upgrade to work?
When you're installing an upgraded bundle, you're installing it, not uninstalling it. So the order is as the FireGiant article specifies for an install: The upgraded bundle is installed (usually upgrading the packages it contains) and the related bundle (the old bundle) is uninstalled. When the old bundle is uninstalled, it knows that its packages have been upgraded so it leaves them alone and just removes its own registration.
If your BA tries to prevent downgrades, it needs to also consider the action. For example, WixStdBA lets the uninstall happen like this:
if (m_fDowngrading && BOOTSTRAPPER_ACTION_UNINSTALL < action)