I have a WIX Project and a Bootstrapper of WIX.
I am using Reboot property of WIX to prompt for reboot machine after setup complete its installation.
But when i run my msi using Bootstrapper then it did not prompt a message for reboot machine.
below is my code that i am using in Product.wxs file in WIX:-
<Property Id="REBOOT" Value="Force"/>
Now i am using chain of msi in Bootstrapper project below:-
<Chain>
<MsiPackage SourceFile=".\Bonjour.msi" Compressed="yes" />
<MsiPackage SourceFile=".\Security_IDTools.msi" Compressed="yes" />
<MsiPackage SourceFile ="$(var.BiodentifySetUp.TargetPath)" Compressed ="yes" DisplayInternalUI="yes" />
</Chain>
But when my last msi run it did not prompt reboot message?
The REBOOT property does not force a reboot, and in the context you're using it is a Windows Installer property not a WiX property. The REBOOT property tells Windows what behavior should occur when a reboot occurs. You need a ScheduleReboot action in your MSI file if you want a reboot at the end of an MSI install and want to ask for it, or a ForceReboot if you want to just do it, as Nimish says.
There is also the question of why you want to force a reboot in the first place. Windows will reboot if something happens that requires one - there's no need for you to assume that a reboot is required just because an install has finished.
A Reboot may be necessary due to the stupid behavior of events and security in Windows 8 (and even in windows 7). That is the "easiest" way to make sure all of your services have been started correctly. I would expect that as already mentioned would be the best choice so that there is no abort of the bootstrapper in the middle.
Priyanka if you have any plans to continue your installation after reboot then do not use the MSI's reboot prompt with a bootstrapper.
That's because it would effectively abort the bootstrapper and won't give it a chance to resume on reboot if necessary.use <ExitCode Behavior="forceReboot" /> after MsiPackage you want it to restart. After a force reboot, Burn will automatically resume after the reboot and rest of your MSI/Exe would be installed.
But if you dont have any such plans you can go with ScheduleReboot Action in your MSI.
<InstallExecuteSequence>
<ScheduleReboot After="InstallFinalize"/>
</InstallExecuteSequence>
This will tell the MSI package to reboot after successful install.
And make sure to check log for any error.
Related
WiX installer uses regular dialogs for specifying the target path:
<UIRef Id="WixUI_Common" />
<UIRef Id="WixUI_InstallDir" />
<Property Id="WIXUI_INSTALLDIR" Value="INSTALLDIR" />
When the user just clicks through the installation wizard the default path is used. The user then runs the program (SomeExecutable.exe) and leaves it running. He then goes to list of programs and asks Windows to uninstall the program. The wizard properly displays a message saying that SomeExecutable.exe is running, so a restart would be needed. That's the expected behavior.
However if the user changes the target to something like c:\UserSpecificedFolder then installation works just fine but when an uninstall is attempted while SomeExecutable.exe is running then unistall finishes without any messages and files are not removed. The program continues running. That's not the expected behavior.
It looks like some extra step is needed to inform the installer that install path was changed and so it should treat the new path as install path when uninstall is being run.
Why would it not work?
What does the Windows Installer uninstall log say? I'm not completely convinced this is a problem even though it seems obvious. WiX only creates MSI databases. It doesn't do the uninstall, MSI does. MSI only prompts file in use / reboot interactions when it isn't able to do an operation. If there is no file lock it may be completely normal to not see it.
My follow up question would be is the file uninstalled at the end without rebooting?
I have the following very basic WIX 3.11 bundle defined at the minute and I have removed the execpackages that fire before the MSI is installed as the problem I'm about to describe only occurs with the MSIPackage command and the specific Third Party MSI I'm using.
<?xml version="1.0"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:bal="http://schemas.microsoft.com/wix/BalExtension">
<Bundle Name="ACME APP 32Bit" Manufacturer="ACME CORP" Version="1.0.0.0" UpgradeCode="0B736949-AE50-46B0-A534-42C9672FAF1F" IconSourceFile='..\Common Files\Images\icon.ico'>
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLargeLicense">
<bal:WixStandardBootstrapperApplication
LicenseFile="..\Common Files\Documents\EULA.rtf"
ShowVersion="yes"
LogoFile="..\Common Files\Images\logo-64x64.png"
LogoSideFile="..\Common Files\Images\logo-64x64.png"
/>
</BootstrapperApplicationRef>
<Chain>
<MsiPackage Id="TP32BIT" SourceFile="ThirdParty.msi" Visible="no" />
</Chain>
</Bundle>
</Wix>
What is happening is after the bundle deploys the MSI and whilst the Installation completed successfully dialog is present , the modify setup dialog again (repair uninstall cancel ).
It only appears to happen with the third party MSI that I need to install. I don't have control over this MSI and nor can I get support on changing from the manufacturer at this time.
I've replaced the MSI with another random product and it doesn't result in the same issue. Its deployed without effectively attempting to run the bundle installer again.
I've run the Third Party MSI from the command line and checked it's return code on instillation and it returns 0.
I'm baffled as to whats causing the installer to think it needs to run itself again on completion of this MSI. Non of the UUIDs are in conflict and I don't think there's anything wrong in my xml.
If anyone can shed some light onto this I'd appreciate it. Currently the only thing I can think of doing is attempting to deploy this specific MSI to the platform via a execpackage approach that runs the msiexec from command line but that completely negates the reason I'm using a bundle in the first place.
Thanks in advance.
I am a little bit confused reading this.
Does the problem manifest itself if you run ThirdParty.msi interactively with full setup GUI outside the Burn Bundle?
In other words a regular installation, that is not invoked via command line but run by double clicking the MSI and then clicking through the setup GUI.
I suppose it is possible that some fancy event in the setup complete dialog kicks off a custom action that does something crazy. Is this an MSI that we can take a look at? Can you provide a download location? (no promises though).
When the setup is run in silent mode, the GUI sequence does not run - which could explain why things work in silent mode - if this is indeed the case.
Turns out it's a known bug in WIX that is triggered by the 3rd Party MSI. github.com/wixtoolset/issues/issues/5266 This MSI can't be changed and has to deploy it's content using this mechanism. I've been able to create a work around to resolve the issue as the installer starts 2 new instances of Wix after the MSI completes so I'm tracking the process IDs and killing anything "unknown" –
I have a bootstrapper which is built using Burn and installs a package which i have setup to allow for minor upgrades when i run the msi packages using REINSTALL=ALL REINSTALLMODE=vomus from the command prompt (as per this article in the WiX docs).
However currently trying to upgrade with the setup.exe returns the message "Another version of this product is already installed..."
How do i get the boosttrapper to upgrade it's packages?
According to this question from 2009 burn "will be able" do the work of starting the MSI in the appropriate mode can it do it now?
I have tried using the MsiProperty element like this:
<MsiPackage Id="PackageId" SourceFile="path\to\my.msi">
<MsiProperty Name="REINSTALL" Value="ALL"/>
<MsiProperty Name="REINSTALLMODE" Value="vomus"/>
</MsiPackage>
But that doesn't seem to do it. What have i Missed?
If you are doing a minor upgrade Burn will automatically detect that and
pass the right switches for you. If you are trying to force it Burn does not support that.
I have a setup MSI for our application, and I also have signed FTDI drivers that need to be installed as well. I'd like for them to be installed with Burn rather than the WiX MSI to keep CustomActions out of the MSI (however, I've tried the CA route as well).
I've tried putting the instruction in an ExePackage, but the SourceFile attribute asks for the file location during build, not runtime (e.g. <ExePackage Id="InstallDrivers" DisplayName="Installing Drivers" SourceFile="[InstallFolder]Drivers\DPInst.exe" InstallCommand="/SA /SW" PerMachine="yes" After="MyMSISetup" Description="Installing the FTDI drivers needed for device communication." /> doesn't build).
Is there a way to tell Burn to execute DPInst using the file location of where the drivers will be after installation of the MSI? Currently the MSI copies the driver files and DPInst into a Drivers folder in the install directory. After looking online and here on Stack Overflow, I doesn't seem like anyone else is doing this.
I've also tried using the CustomAction route in the MSI, but the CustomAction fails to execute. I'd like the drivers to be installed with Burn, but if they work with the MSI I'd settle for that. Currently the MSI copies the files to the Drivers folder, and the CustomAction looks like this:
<InstallExecuteSequence>
<Custom Action="Install_Signed_Driver" After="InstallFiles">NOT INSTALLED</Custom>
</InstallExecuteSequence>
<Fragment>
<CustomAction Id=Install_Signed_Driver" Execute="deferred" Directory="Drivers" ExeCommand="[Drivers]DPInst.exe" /SW /SA" Return="ignore" />
</Fragment>
As near as I can tell, the custom action never runs. I've even taken off the /SW and /SA switches to see if anything loads, and nothing.
Per StackOverflow's suggestion, I'm posting what I found here. I was never able to get Burn to run DPInst for the driver installation, but was able to get the CustomAction to work using Can't seem to get Wix to install driver.
We need to deliver Hotfix KB982638 to our clients due to a requirement in our products. Our installers are based on WIX.
How can we launch Hotfix KB982638 from our installers, at the end of installation?
What we tried:
We tried to launch its .exe from within our .msi, but it started waiting to finish our msi process, which was actually waiting for hotfix to finish its process and so both halted.
Here is the code:
<Binary Id="NDP40_x64" SourceFile="D:\ApBuild\src\bpf\extras\bin\NDP40-KB982638-x64.exe" />
<CustomAction Id="NDP40_x64_install" Return="ignore" Execute="deferred" BinaryKey="NDP40_x64" ExeCommand=" " />
<InstallExecuteSequence>
<Custom Action="NDP40_x64_install" After="InstallFiles"><![CDATA[Not REMOVE]]></Custom>
</InstallExecuteSequence>
We also tried to launch it from a Bootstrapper (setup.exe) while turning off Hotfix restart option and enabling Bootstrapper's option with Defr attribute, but in this case, if system is restarted, installation of Hotfix also restarts and so a loop is created.
Any help would be greatly appreciated.
Thanks and best regards
Farrukh
Schedule your CA launching the hotfix after InstallFinalize. It should not wait for your installation to finish.
Ok, so I was able to solve it. The Hotfix installer itself installing *.msp files and we can't launch these from out msi installer, it hangs always.
Solution is to pack it with Setup.exe (bootsrapper application ) and installs before launching the msi.
So I launched Hotfix while passing parameter to not to restart until it finished and then I launched the msi which has a scheduled restart custom action.
Thanks a bunch guys
Farrukh