I have made a burn bundle which encapsulates 2 msi (msi1 , msi2) . In the UI I use checkboxes to ask the user to select which MSI to install.
Now if user selects one of the msi to install, installation goes fine. But during Uninstall action, the burn log file says :
[][:15]: Detected package: Netfx4Full, state: Present, cached: None
[][:15]: Detected package: DummyInstallationPackageId3, state: **Absent**, cached: None
[][:15]: Detected package: msi2.msi, state: **Present**, cached: Complete
[][:15]: Detect complete, result: 0x0
[][:16]: Plan 3 packages, action: Uninstall
[][:16]: Will not uninstall package: msi2.msi, found dependents: 1
[][:16]: Found dependent: {08e74372-83f2-4594-833b-e924b418b360}, name: My Test Application
In the install scenario, I chose to install msi2 and NOT msi1.
My bundle code looks like:
<Bundle Name="My Test Application" Version="1.0.0.0" Manufacturer="Bryan" UpgradeCode="CC2A383C-751A-43B8-90BF-A250F7BC2863">
<Chain>
<PackageGroupRef Id='Netfx4Full' />
<MsiPackage Id="DummyInstallationPackageId3"
SourceFile="msi1.msi"
ForcePerMachine="yes"
InstallCondition="var1 = 1"
>
</MsiPackage>
<MsiPackage
SourceFile="msi2.msi"
Vital="yes" Cache="yes" Visible="no"
ForcePerMachine="yes"
InstallCondition="var2 = 2"
>
</MsiPackage>
</Chain>
My OnDetectPackageComplete() looks like:
private void OnDetectPackageComplete(object sender, DetectPackageCompleteEventArgs e)
{
if (e.PackageId == "DummyInstallationPackageId3" )
{
if (e.State == PackageState.Absent)
InstallEnabled = true;
else if (e.State == PackageState.Present)
UninstallEnabled = true;
}
}
What should I do so that the burn bundle is freely able to uninstall the msi which the user selected at the time of install. Besides, If I select both msi to install, then uninstall is working fine.
IMO, there is some problem b/w the relation of bundle and the 2 msi. Please help me as I am stuck with this problem.
Your registry could be messed up from a lot of trial and error with creating your first Burn bootstrapper. I would suggest trying the following:
Search the registry for the "dependents" (ex: {08e74372-83f2-4594-833b-e924b418b360}) and delete those keys
Uninstall the application (should succeed)
Search the registry for the product code of the other .msi that you had installed before. Verify it is not in the registry. If it does exist, delete those keys.
Try reinstalling and see if you can uninstall ok.
Related
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.
A simple msi created using WiX. Trying to install a product. On some computers it will fail, without an error, and the installer log will contain these rows:
PROPERTY CHANGE: Adding WIX_UPGRADE_DETECTED property. Its value is '{7C9...0A0}'
PROPERTY CHANGE: Adding MIGRATE property. Its value is '{7C9...0A0}'
Product Code from property table after transforms: '{68F...FAE}'
Product not registered: beginning first-time install
Doing action: INSTALL
Doing action: InstallValidate
Feature: ProductFeature; Installed: Absent; Request: Null; Action: Null
MIGRATE = {7C9...0A0};{A9B...BCE}
Installation completed successfully.
Somehow, Windows Installer decides that there is nothing to do (Request: Null), even though it acknowledges that this is the first time install. That computer had previous version of the product installed. How do I force the installer to install?
Here is the relevant WiX code:
<Product Id="*"
Name="..."
Language="1033"
Version="..."
Manufacturer="..."
UpgradeCode="8D8...196">
<Package Id="*"
InstallerVersion="200"
Compressed="yes"
InstallScope="perMachine"
InstallPrivileges="elevated"
Platform="$(var.Platform)" />
<Property Id="REINSTALLMODE" Value="amus" />
<MajorUpgrade AllowDowngrades="yes" IgnoreRemoveFailure="yes" AllowSameVersionUpgrades="no"/>
<Feature Id="ProductFeature" Title="..." Level="1" Absent="disallow" AllowAdvertise="no" InstallDefault="local" TypicalDefault="install">
<Condition Level="1">True</Condition>
Full installer log: https://www.dropbox.com/s/abnryavh203a82w/acme_installer_log.txt?dl=0
You did not set MigrateFeatures in your MajorUpgrade element. The documentation says the default value is Yes.
http://wixtoolset.org/documentation/manual/v3/xsd/wix/majorupgrade.html
The log shows you are doing an upgrade, therefore the only features that are going to be installed is the same set that are already installed.
It's not clear how many features there are in your product, but if you always want all features to be installed during an upgrade set MigrateFeatures to No.
Either way, it would be better to supply the entire log to see what's going on and if there is another explanation.
This got too long for a comment, adding as an answer. Just a couple of things:
You definitely should not set REINSTALLMODE="amus" for any MSI package.
If you include merge modules in this setup you could downgrade shared files - even if you otherwise don't write to shared locations yourself.
The best would be the default "omus", but I guess "emus" is also ok (Reinstall if the file is missing, or is an equal or older version).
It certainly looks like the MigrateFeatureStates action is at least related to the problem seen:
MigrateFeatureStates: based on existing product, setting feature 'ProductFeature' to 'Absent' state.
Your INSTALLLEVEL property looks fine.
You might want to open the compiled MSI and verify that there are no entries in the Condition table (which can change feature selection states). There should be nothing there, but perhaps just verify.
I suppose you could try to set the Absent attribute for the WiX Feature element to "disallow", recompile and see if this changes things. If this is your only feature I would make this change in addition to using Phils suggestion to set MigrateFeatureStates to "No". Why allow your only feature to be removed?
It is a little odd how this problem has occurred. Perhaps you ran modify on your MSI and simply selected the feature to be uninstalled in the old installation on the machine? Sounds unlikely - especially if it is your only feature.
Did you install several earlier versions of your product on the machine in question, or was there only one prior version?
Again, are there entries in the "Condition table" in the compiled MSI? (Check using Orca).
Did you change the feature name in your newest package?
In any event you should be able to "fix" the broken install by 1) simply running your existing setup and adding ADDLOCAL=ALL to your msiexec.exe install command - I think that will override the MigrateFeatureStates action (not a real fix, just a workaround). Or 2) you can disable MigrateFeatureStates and recompile the setup - that should fix things permanently, and 3) if I were you I would set the Absent attribute for the WiX Feature element to "disallow" so that your (only?) feature can't be removed.
Phil, if you see this, do you know what the MIGRATE property seen in the log is about? It looks like some WiX specific stuff - unless it is something from this MSI's upgrade table:
MSI (c) (04:24) [13:01:38:751]: Doing action: FindRelatedProducts
MSI (c) (04:24) [13:01:38:751]: Note: 1: 2205 2: 3: ActionText
Action 13:01:38: FindRelatedProducts. Searching for related applications Found application: [1]
Action start 13:01:38: FindRelatedProducts.
FindRelatedProducts:
MSI (c) (04:24) [13:01:38:751]: PROPERTY CHANGE: Adding WIX_UPGRADE_DETECTED property. Its value is '{7C945F97-A2CC-4EEB-87AC-3D23D6C490A0}'.
MSI (c) (04:24) [13:01:38:751]: PROPERTY CHANGE: Adding MIGRATE property. Its value is '{7C945F97-A2CC-4EEB-87AC-3D23D6C490A0}'.
FindRelatedProducts:
MSI (c) (04:24) [13:01:38:752]: PROPERTY CHANGE: Modifying WIX_UPGRADE_DETECTED property. Its current value is '{7C945F97-A2CC-4EEB-87AC-3D23D6C490A0}'. Its new value: '{7C945F97-A2CC-4EEB-87AC-3D23D6C490A0};{A9B1787A-32E4-4D51-819D-B3F879574BCE}'.
MSI (c) (04:24) [13:01:38:752]: PROPERTY CHANGE: Modifying MIGRATE property. Its current value is '{7C945F97-A2CC-4EEB-87AC-3D23D6C490A0}'. Its new value: '{7C945F97-A2CC-4EEB-87AC-3D23D6C490A0};{A9B1787A-32E4-4D51-819D-B3F879574BCE}'.
Action ended 13:01:38: FindRelatedProducts. Return value 1.
tandrasz: as far as I can see the two GUIDs that are found by FindRelatedProducts ({7C945F97-A2CC-4EEB-87AC-3D23D6C490A0};{A9B1787A-32E4-4D51-819D-B3F879574BCE}), are different from your new setup's product code ({68F5E655-2E2D-492E-B445-BE1650AF5FAE}). This makes it look like there are two "related products" found by FindRelatedProducts on the machine in question. Are two older versions of the same MSI installed, or do you have a "suite" of MSI files that all share the same upgrade code?. If you have two "unrelated" packages installed, perhaps MigrateFeatureStates finds no way to migrate the feature states between those two and the new package you are installing?
I am using the following code to start a Setup program at the end of my Installation (also with elevated permissions):
<Product ... >
...
<InstallExecuteSequence>
<Custom Action='LaunchSetupAction' After='InstallFinalize'/>
</InstallExecuteSequence>
<!-- Workaround required for Windows7, Setup.exe can not be started directly because of UAC
http://stackoverflow.com/questions/2325459/executing-a-custom-action-that-requires-elevation-after-install -->
<Property Id="WixShellExecTarget" Value='[#SetupEXE]'/>
<CustomAction Id="LaunchSetupAction" BinaryKey="WixCA" DllEntry="WixShellExec" Execute="immediate" Return="check" Impersonate="yes"/>
...
<MajorUpgrade DowngradeErrorMessage="A later version of [ProductName] is already installed. Setup will now exit." />
</Product>
This works well when then program is installed freshly, but when it is upgraded from a previous version with the same code, the installation reports a fatal error and fails.
In the Windows installer log I have found the following:
Action start 23:42:22: LaunchSetupAction.
...
MSI (s) (38:88) [23:42:22:342]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI679.tmp, Entrypoint: WixShellExec
...
WixShellExec: WixShellExecTarget is C:\Program Files\Me\MySetup.exe
...
WixShellExec: Error 0x80070002: ShellExec failed with return code 2
...
WixShellExec: Error 0x80070002: failed to launch target
...
Action ended 23:42:22: LaunchSetupAction. Return value 3.
Action ended 23:42:22: INSTALL. Return value 3.
Interesting enough these error messages (file not found?) is also there when I comment out the CustomAction in the new version of the installer.
Why is this CustomAcount executed from the previous version to be uninstalled?
Is there any way I can stop it from being run? After a certain point of the upgrade, the MySetup.exe is just not there anymore and will always cause a fatal error ...
That custom action has no condition on it, so it will be called on all types of installer operations, such as uninstall, add/remove features etc. Your upgrade is an install of the new product and an uninstall of the old product.
You need this kind of thing on your custom action:
Wix: Run custom action based on condition
so a condition of 'Not Installed' causes the CA to run only if the product is not already installed.
You can't really fix this because the uninstall for that product is embedded in the system. You'd need to fix that older version of the product by rebuilding the exact same product with the custom action condition fixed and then fix it with:
msiexec /i [path to new MSI] REINSTALL=ALL REINSTALLMODE=vomus
If you're very familiar with MSI and Orca, you may be able to locate the cached MSI file in C:\windows\installer, open it with Orca, go the InstallExecuteSequence and give that custom action a condition of 0, then save it. That basically corrects the uninstall sequence so that your upgrade will work. Caveat Emptor.
It also appears that a plain uninstall would give you same error - did you every try to do an uninstall test?
I am developing a wix installer. This wix installer installs a 3rdparty msipackage.
I want my wix bootstrapper project to install this msipackage no matter what version that should already exist on the users pc. This means that if the same version(or a newer version) exists it should overwrite that installation.
I install my msipackage like this:
<MsiPackage Id="InstacalFull" Name="Measurement Computing InstaCal" Vital="yes" Compressed="yes" SourceFile="../Suite.SetupBootstrapper/3rdparty/Instacal/InstaCal.msi">
Does anyone have any ideas on how to achieve this?
Use InstallCondition="1"
This will install it every time
http://wixtoolset.org/documentation/manual/v3/xsd/wix/msipackage.html
InstallCondition
String
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.
I know this one is old, but since I came across this issue, maybe it would help someone, too.
In my case Repair was enough, so although technically it wasn't reinstall, practically Repair = Reinstall.
I needed to reinstall URLrewrite, because it could get broken when IIS Windows feature was disabled.
What you need it to add custom handler for PlanPackageBegin in you custom BootstrapperApplication class, for example:
CustomBootstrapperApplication.Model.Bootstrapper.PlanPackageBegin += this.PlanPackageBegin;
...........
private void PlanPackageBegin(object sender, PlanPackageBeginEventArgs e)
{
if (e.PackageId.ToLower().Contains("urlrewrite"))
{
if (CustomBootstrapperApplication.Model.Command.Action != LaunchAction.Uninstall && e.State == RequestState.Present)
{
CustomBootstrapperApplication.Model.Engine.Log(LogLevel.Verbose, string.Format("{0} is installed, forcing Repair", e.PackageId));
e.State = RequestState.Repair;
}
}
_packageList.Add(e.PackageId, e.State);
}
And in the the Bundle:
<!-- Note: this Id is used in PlanPackageBegin -->
<MsiPackage Id='urlrewrite2X64' Vital='no'
Permanent='yes'
SourceFile="rewrite_amd64.msi"
DownloadUrl="http://example.com/rewrite_amd64.msi"
DisplayInternalUI="no"
Visible="yes"
InstallCondition="VersionNT64"/>
You can force uninstallation of previous MSI during upgrade by something like this inside PlanPackageBegin:
if (LaunchAction.Uninstall == CustomBootstrapperApplication.Model.Command.Action && (CustomBootstrapperApplication.Model.Command.Relation == RelationType.Upgrade))
{
e.State = RequestState.None;
}
I'm having issues with with a custom action I want to run during uninstall.
The custom action is responsible for unregistering a system level windows service.
Custom action:
<CustomAction Id='UnregisterService'
Directory='INSTALLDIR'
ExeCommand='[INSTALLUTIL] /u "/config=[INSTALLDIR]\configInstall.xml" " ...
Return='ignore'
Execute='deferred' />
This action scheduled in the InstallExecuteSequence and should be invoked on uninstall and upgrade:
<InstallExecuteSequence>
<Custom Action="PreventDowngrading" After="FindRelatedProducts">NEWPRODUCTFOUND</Custom>
<RemoveExistingProducts After="InstallValidate" />
<Custom Action='UnregisterService' After='InstallFiles'>UPGRADEFOUND OR (Installed AND NOT UPGRADINGPRODUCTCODE)</Custom>
<Custom Action='RemAgApps' After='UnregisterService'>UPGRADEFOUND OR (Installed AND NOT UPGRADINGPRODUCTCODE)</Custom>
...
</InstallExecuteSequence>
The problem is that when I run uninstall from the ARP, uregister action does not invoked (as written in msi logs):
Skipping action: UnregisterService (condition is false)
When I dig deeper into the log (which is terrible...) I see that there is no 'uninstall' action, only install:
Property(C): EXECUTEACTION = INSTALL
Property(C): ACTION = INSTALL
Product: BLABLA -- Installation completed successfully.MSI (c) (BC:50) [14:35:37:067]: Windows Installer installed the product. Product Name: BLABLA . Product Version: 5.1.0. Product Language: 1033. Manufacturer: BLABLA Team. Installation success or error status: 0.
My questions are :
What is the flow of msi uninstall? (No couldn't find it in the web...)
Why I get the 'Install' action during uninstall?
How can I force uninstall to run my 'unregisterService' custom action?
Thanks!
Custom actions should be avoided until you fully understand Windows Installer to avoid reinventing the wheel with a more fragile solution. To remove a service during uninstall you merely need:
<ServiceControl Id="myService" Name="MyService" Stop="both" Remove="uninstall"/>
Read this good article: InstallSite: Installation Phases and In-Script Execution
Windows installer installation transactions can take many forms. Initial install, repair, maintenance install, uninstall, upgrade, patch and so on. The installer tracks the state change of features, components and products at different levels so the concept of install/uninstall is more detailed.