So I have a Wix 3.0 project that installs an IIS7 Native Code Module. When uninstalling I would like to be able to shut down the IIS7 application pools before deleting the file so that a reboot is not necessary.
I am using the appcmd utility to shut down the app pools in a CustomAction element, but when I attempt to do an uninstall I get this error before the customaction is ever invoked:
The setup must update files or
services that cannot be updated while
the system is running. If you choose
to continue, a reboot will be required
to complete the setup.
I have the "After='InstallInitialize'" property set on the CustomAction, because the documentation says that any deferred/not-impersonated custom action must come between InstallInitialize and InstallFinalize.
So is there some way to have a custom action execute before this check for files in use is made? Or disable this check for a given file, or make the check happen later in the sequence?
Yes, you can specify the order for actions to occur by modifying the Sequence column in the InstallExecuteSequence table within the MSI file.
Get the ORCA tool to examine the MSI file to see what I mean, and use a Javascript script to modify the MSI as appropriate.
Related
Working with Wix in Visual Studio. I have a public property defined in Product node of wxs file.
<Property Id="MYPROP" Value="123456789"/>
The property value is passed as commandline argument to a deferred custom action executable. I'm able to receive it in the exe as well. The problem is even if I update the Property using vbs (verified through vbs select as well), when I launch the msi, it still passes the default/original value (123456789) to the custom action executable.
Also tried msiexec.exe /i myinstaller.msi MYPROP=SomeOtherValue
I'm still seeing the original value. What's wrong?
Maybe try this simple thing first:
<Property Id="MYPROP" Secure="yes" Value="123456789"/>
Essentially you need to add a property to the SecureCustomProperties list to have them pass properly to deferred mode in secure desktop environments.
See more information on SecureCustomProperties here. The technical details here are a little bit in flux because of Windows changes, so please just try this first - there could be several other reasons.
How do you use this property? What does it do?
When an msi is run, windows caches the msi file in %windows%\Installer folder. When that msi is run again, windows checks if an msi with identical PackageCode exists in the cache, if so then it uses the cached msi file instead.
PackageCode: identifies each unqiue msi installer package - even if it only has different properties.
In short, when a property is updated using a vbscript etc, then the PackageCode has to be updated as well. This will ensure that after updating msi, the same msi can be used on the same system and windows will not use the cached msi.
I would like my MSI to self-delete after the installation process is complete. How can I achieve this? Anyway to do it in WIX only? Do you have to create a custom action?
For those wondering, this installer is generated on the fly and bundled to a specific configuration. After the installation is complete, the MSI file has no use anymore (the user must download a new installer with a fresh configuration to reinstall).
This isn't going to be useful, mainly because the MSI file is needed after the install is complete. Rule 31:
http://blogs.msdn.com/b/windows_installer_team/archive/2006/05/24/605835.aspx
Any kind of repair (automatic or user repair) will require the original MSI file. You're better off deleting it at uninstall time.
In general, the way I've done this type of thing is to get an executable into the user's temp location (don't install it there, copy it there with a custom action) and arrange for it to run and delete the MSI file. Just rely on eventual cleanup of the temp directory to delete the exe. However, it won't be transparent if it requires elevation to do the delete, and popups of unfamiliar programs asking for elevation may get denied.
When I repair using the msi, a registry entry is properly re-created. When using the exe generated by Burn, the entry is not-recreated, unless the exe associated with the reg entry also requires compare.
I wonder if, when burn invokes msi, if it is overriding the default /fm behavior of msiexec.
That switch means "repair all required computer-specific registry entries "
Is there any way I can confirm, deny, or modify that behavior?
When planning a "Repair" operation in Burn the REINSTALLMODE is "cmuse". For a "Modify" operation the REINSTALLMODE is "cmuso". So "m" is present in both cases.
The Burn log file should say, "Planning action: Action" and that will tell you which it is doing. If you are executing a Repair operation and there is not newer version of the executable on the machine than what your MSI expects, Burn's REINSTALLMODE should work. If you are doing a "Repair", look in the generated MSI log file for the same Burn execution and see what the Component states are for the Components that are not repaired. That should help you track back to see why the Component was not fixed.
From the provided log file:
Command Line: ARPSYSTEMCOMPONENT=1 MSIFASTINSTALL=7 REINSTALLMODE=cmuse
REBOOT=ReallySuppress IGNOREDEPENDENCIES=ALL CURRENTDIRECTORY=C:\temp
CLIENTUILEVEL=3 MSICLIENTUSESEXTERNALUI=1
The lack of REINSTALL=ALL shows that EnableFeatureSelection='yes'. Either remove that attribute (or change it to the default 'no') or your BA needs to handle the OnPlanMsiFeature() callback
I have a situation where I have been asked to re-implement and InstallShield installer in Wix. I am having difficulty with examples on the Internet trying to implement the exact behavior. What I need to do is the following:
When the user clicks the Install button on the VerifyReadyDlg (I am using Mondo) and the ProgressDlg comes up:
Call a .exe in the install location (if exists from a previous install)
Stop a service in the install location (if exists from a previous install)
Unregister the said service (if exists from a previous install)
Copy files from the MSI, including a copy of the service .exe to install location
Read data from some Edit controls on a previous dialog and write the data to some of the copied .xml configuration files that are now in the install location
Register the service again
On clicking the Finish button on the very final dialog (ExitDlg) I need to:
Start the service again
Call an .exe (different to the first one) in the install location
I can copy files and write data to some of the files after they have been copied...though Wix just does this...I don't tell it when to go and do it. The problem is I need to schedule the first .exe call, Service Stop and Unregister before the Copy action starts and I can only Register again AFTER the .xml config files have been updated.
I have been trying to use InstallExecuteSequence and ServiceInstall elements and tying them together with CustomActions, but it's not coming together and I think I am totally approaching this the wrong way...it's not worth posting what I have done.
How should I go about this? This is a common pattern that I have seen in InstallSheild scripts, yet I can't find any Wix examples doing this sequence.
Thanks a HUGE bunch for any help on this.
Michael.
You can control when your actions are scheduled using Before or After attributes of Custom element or the elements for standard actions.
Is the current installation made with MSI? If yes, you may want to do upgrade installation and schedule RemoveExistingProducts after you copy existing config but before other install actions are performed. This way the previous package will be removed with its own uninstall logic, and then you can install the updated package.
To save configuration from the previous version, you have to run an action before RemoveExistingProducts is executed.
You may wish to use a Custom Action that you define in C# from a project you create that outputs to a DLL file:
public static class CustomActions
{
[CustomAction]
public static ActionResult DoSomething(Session session) {
// Put C# code here that does what you describe, such as run an exe
// from the command prompt.
return ActionResult.Success;
}
}
Import this DLL into your Wix installer:
<!-- The custom action DLL itself.-->
<Binary Id="WebAppCA" SourceFile="$(var.SolutionDir)..\WebAppInstallCustomActions\bin\Debug\WebAppInstallCustomActions.CA.dll" />
<!-- The custom action that does something that you can use. -->
<CustomAction Id="DoSomething"
BinaryKey="WebAppCA"
DllEntry="DoSomething"
Execute="immediate"
Return="check" />
If you wanna check out a complete solution, see this thread on John Robbins' Blog (link)...he has a Wix installer that installs an IIS site but when you start it, it uses a Custom Action defined in C# to enumerate a list of web sites.
I have a file which is not installed:
<Binary Id="LaunchMyExe" SourceFile="$(var.Project.DependenciesPath)/myProgram.exe" />
And I would like to run it quietly during the InstallUISequence but I can't..
How to link the BinaryKey of this file to the CAQuietExec custom action?
Any sample appreciated.. thanks!!
You'll have to author another custom action, which will extract that file from Binary and place to some folder known to your "LaunchMyExe" action, for instance, Temp folder.
Is your program a console application? If it's a regular GUI application, you, most probably, don't need CAQuietExec action because you can run it directly with CustomAction element.
Set these properties:
BinaryKey="LaunchMyExe" - this is the key into the Binary table where your exe is stored.
ExeCommand="" - this tells WiX and Windows Installer you want type 2 custom action.
set other properties as appropriate.
If your application is a console one, then you would need WiX Quiet Execution Custom Action to hide the console window while it runs.
These links would help you:
Quiet Execution Custom Action gives examples on how to use QtExec action.
How To: Run the Installed Application After Setup for an overview on using custom actions.