I have one WiX setup project which produces my application's msi installer and I have also setup the uninstall shortcut feature for the application. In addition, I have a WiX bootstrapper project which detects and install .NET and VC++ during installation on the user's computer.
The bootstrapper works fine and can detect and install .net and vc++, and also install my application.
However, the issue I am facing is that when I uninstall my application using the shortcut in the Program Menu folder, it can successfully uninstall my application but there still is an entry of the bootstrapper in the "Add and Remove Programs(ARP)". I have to manually uninstall it by going on to the ARP.
My question is: How do I uninstall the bootstrapper exe without having to go to the ARP everytime? My msi uninstalls fine from the shortcut but I do not know how I can uninstall the exe with a shortcut.
This is how my bootstrapper bundle looks like:
<Chain>
<!-- NetFx46Web: Checks whether .NET 4.6 is installed in user comp. If not, install it via a web installer -->
<PackageGroupRef Id="NetFx46Web"/>
<!-- VC++ 2013 install -->
<PackageGroupRef Id="vcredist2013_x86"/>
<!-- Reference the setup msi installer -->
<MsiPackage Id="my_msi" SourceFile="$(var.InstallProj.TargetPath)" DisplayInternalUI="yes" />
</Chain>
Related
My Wix bundle is installing a few 3rd party EXE packages that are packaged with Inno setup. As you know, Inno Setup uninstaller is a separate executable. Basically, when you install AThirdParty.EXE - it creates an unin000.exe within its deployed folder ( e.g. C:\Program Files (x86)\AThirdPartyApp\unins000.exe ), and that's what I need to execute during my bundle uninstall.. Anyone know how to it with Wix Bootstrapper?
Below is an example of my ExePackage:
<PackageGroup Id="MyThirdPartyPackages">
<ExePackage Id="AThirdPartyExe"
DisplayName="A Third Party Exe"
Cache="yes"
Compressed="yes"
PerMachine="yes"
Permanent="no"
Protocol="none"
Vital="yes"
SourceFile=".\AThirdPartyExe.exe"
DetectCondition="AThirdPartyExeExists"
InstallCommand="/VERYSILENT /SUPPRESSMSGBOXES"
UninstallCommand="[ThirtdPartyEXEPath]\unins000.exe" <!-- Can I use uninstallcommand for this?? -->
/>
</PackageGroup>
Assuming Inno Setup doesn't support an /uninstall flag (no idea but if so yet another reason to only use MSI ) and you don't want to repackage the installer into an MSI the quickest solution I can think of is a man in the middle EXE.
InstallShield used to (may still) have a Helper.exe for some of it's setup prerequisites. You would code it to accept a /INSTALL and /UNINSTALL argument and have WiX call that instead. It would in turn call the actual install and uninstall as you described above.
I have an msi bundled with prerequisites using Wix bootstrapper (burn.exe).
We migrated this project from Installshield to WiX.
The installation works fine.
However, during repair or uninstall the bootstrapper runs the msi-file in silent mode.
Since the last dialog (e.g. 'SetupCompleteSuccess') within the msi file contains some controls to trigger some more actions.
Is there a possibility to configure the bootstrapper so that the msi file is executed in 'UI'-mode?
In WiX v3, it is not possible. Burn explicitly shows internal UI only during initial install. WiX v4 changes how that works: https://github.com/wixtoolset/issues/issues/5616
We are upgrading our WIX msi installer (not a bundle) with manual pre-requisites to a Managed custom Bootstrapped application Bundle. The boot strapped custom installer bundle exe works fine for fresh installs. But if we want to upgrade our older product which is just an msi, we are in trouble. This is what I am trying to do
Detect RelatedMsiFeatureHandler detects there is an older msi package installed.
I am handling the Plan events for individual packages and setting the states as desired. For ex: state = Present for install
I cannot to Apply(UpdateReplace) because I do not have an older Bundle,
The million dollar question is how do I upgrade this msi package?
Any help is appreciated.
Thanks
All I had to do was set the MsiProperty UPGRADE=1 in Bundle.wxs for the relevant Msi Package in the chain. This made sure that when the Bundle.exe is run the specific msi is upgraded BTW: this is the first version of Bundle for us. We had just an MSI before for installation.
<MsiPackage DisplayName="Installing Main Product" SourceFile="$(var.Path_Setup)" DisplayInternalUI="no" SuppressSignatureVerification="yes" >
***<MsiProperty Name="UPGRADE" Value="1"/>***
<MsiProperty Name="NAS_PATH" Value="[NasBackupPath]"/>
<MsiProperty Name="NAS_BAK_TIME" Value="[BackupTime]"/>
</MsiPackage>
</Chain>
Just in case if anyone having similar issue (WIX 3.10)
this statment under the installer's Product will resolve the issue. You must update the version of the product and product upgrade code must be same with previous install.
"AllowSameVersionUpgrades" = yes will make sure not to install same product side by side.
The situation:
I have a WIX-based bootstrapper installer, which installs my msi package and (some) prerequisites (.NET). The installer is .exe and it works ok.
Now, some clients want to install msi, especially in corporate environments where they can push it centrally.
It looks easy, just give them the msi. Again, It works ok.
Now, the problematic part.
When the application is installed from MSI, and later upgraded to newer version from .exe installer, there will be two ARP entries. And vice-versa - when the application is installed from .exe, and later upgraded from MSI, there will be double ARP entries again.
Is there any easy/standard solution?
To maintain the visibility as Bundle: visible, MSI: not visible, you can either:
Install the upgrade the same way that the bundle does, passing ARPSYSTEMCOMPONENT=1 to msiexec, or
Change your MSI Product so that it defaults to not visible: <Property Id="ARPSYSTEMCOMPONENT" Value="1" />
(In your bundle, MsiPackage/#Visible seems to effectively be "no", which is the default.)
Im using WiX to install my .msi, I´m generating a WiX Bundle using the Bundle Element.
I try to not show the Bundle on "Add/Remove programs" so i set the properties of the Bundle element like this:
<Bundle Name="$(var.ProductName)" Version="!(bind.packageVersion.MSIPackage)"
Manufacturer="$(var.ProductManufacturer)" UpgradeCode="$(var.UpgradeCode)"
DisableRemove="yes" DisableModify="yes" DisableRepair="yes">
DisableRemove, DisableModify and DisableRepair to "yes" made the Bundle be hidden under "Add/Remove programs".
My problem is that when i Uninstall my application, the application is uninstalled correctly but the Bundle remains Hidden, so it cause some problems when i try to install other version of the App, for example the new Bundle detects that there are other Bundle installed and performs some versioning check and so on.
So my question is: is possible to when the application in uninstalled from the "Add/Remove programs" uninstall the Hidden Bundle as well?
To expand on Tom's answer, if you remove the Disables from your Bundle tag
<Bundle Name="$(var.ProductName)" Version="!(bind.packageVersion.MSIPackage)"
Manufacturer="$(var.ProductManufacturer)" UpgradeCode="$(var.UpgradeCode)">
You can modify your MsiPackage tag to hide the MSI from Add/Remove Programs
<MsiPackage
Id="YOUR-ID"
Vital="yes"
DisplayName="$(var.ProductName)"
SourceFile="$(var.Source.TargetPath)">
<MsiProperty Name="ARPSYSTEMCOMPONENT" Value="1"/>
</MsiPackage>
This will leave just one entry in Add/Remove Programs. Your Bundle will now handle the UI of the install and uninstall, and will correctly allow other versions of the bundle to be installed.
Well, you could use a custom action in the msi but don't.
You have inverted the designed relationship between bundles and packages. I suggest that you hide the package and show the bootstrapper in ARP.
The bootstrapper engine ("burn") is a package manager that collaborates with Windows Installer. Together they handle upgrades and uninstallation of packages. If, after understanding how it works, you don't want what it does then you may want a self-extractor instead of burn. (Some projects that do use burn are Visual Studio and WiX itself.)
Use -repair option when running the installer every time. It's a hack but it works. The problem is that the bundle uninstall is hidden, and when running uninstall you are only removing the package inside, not the bundle.
This causes the issue when you want to run the installation again after uninstalling the package inside. The installer thinks that the bundle is still installed. By using the -repair option (every time you install the bundle), you are telling it to either install the bundle if no bundle is present. or repair it if the package was removed.
-repair = repair (or install if not installed)