I have been tasked with writing a WIX installer from an application that uses Firebird 1.5. The WIX install process must launch the firebird installer if firebird has not already been installed. Using a custom action I get the firebird installer to launch but end up with error "1607 unable to install installshield scripting runtime". I have searched this error but have not been able to find a resolution.
Here is a snipit of my custom action.
<InstallExecuteSequence>
<Custom Action='LaunchFirebirdsetup' Before='InstallFinalize'>NOT Installed</Custom>
</InstallExecuteSequence>
<CustomAction Id='LaunchFirebirdsetup' FileKey='Firebird15Setup' ExeCommand='' Return="ignore" Execute="commit" Impersonate="no" />
It might be because you cannot run an MSI install from within an MSI install, I think that's still true even with a Commit custom action. Your IS Script install is an MSI install, so that may be the issue. Launching installs from within installs is always an issue. You should use Burn to launch that Firebird install before installing yours. That's what a Burn bundle is for - prerequsites and associated installs as well as your MSI setup. You could use it to install a standalone ISScript MSI, that's another possibility.
The other issue is that some installs just don't work when installed with no impersonation, which means with the system account. There's no indication that you tried to do it silently, which means that it's running with the system account and may attempt to show UI to the interactive user, and that will fail. This another reason to install it with Burn - it will run as the interactive user.
Looks like bootstrapping (burn) is the solution.
Took me a while to get it but after getting it to run, it makes sense I guess.
Instead of running an installer exe you could use merge modules. For instance the Firebird 1.5 Merge Modules from MWA Software. Modules, installation instruction and source for the merge modules are freely available.
Related
I am learning windows installer xml(WIX) and have a condition in my code which checks if software-A is installed before my software is installed.
I want my software could be installed when software-A has been installed but when I am uninstalling my software, this condition should not be triggered.
The bundle works fine when it is in the installing process, that means if software-A has already been installed, it will continue to install. But if software-A has not been installed at all, the bundle will trigger condition checking process, show the condition message and stop installing. I have tried two conditions "NOT Installed" and "Installed", but the condition checking process is still triggered all the time even it is in uninstalling process. That means whatever the process is the bundle always searches the same registry.
The logic of the installer is simple enough but I am a beginner on Windows installer xml technology.
<bal:Condition Message="Software-A is Required.">
<![CDATA[NOT Installed OR SoftwareAInstalled]]>
</bal:Condition>
<util:RegistrySearch Id="SoftwareAInstalled"
Root="HKLM"
Key="SOFTWARE\SoftwareA\"
Variable="SoftwareAInstalled"
Result="exists" />
I wanna know how to prevent the checking process when the installer is in the uninstalling. Or any other suggestions would be appreciate.
Since you want to detect the state of your Bundle you should have a look at Burn Built-in Variables. WixBundleInstalled will give you the installation state of the current Bundle. Therefore
WixBundleInstalled OR SoftwareAInstalled
Will allow the installer to continue if either the current bundle is already installed or if you are performing a fresh install of the bundle and Software A is already present.
I don't have time to verify this right now, but it looks like you can use:
Installed OR SoftwareAInstalled
I would uppercase the latter property, but then it can be set at the command line. I guess it should work with what you have. Can't test right now. Tip: Remember to test in silent installation mode, in modify, repair, self-repair, uninstall, major upgrade, etc... Lots to check.
Some previous answers on similar issues:
Check if prerequisites are installed before installing a windows installer package
How to add new framework version in Installment Requirement page of InstallShield?
WIX Installer: Prevent installation on Windows Server 2012 R2 (on how to debug conditions)
Comment on the OR Installed construct
I am running the .exe file through a CustomAction in Wix. The executable is running but not with admin rights. Seems like i am doing everything correct but not sure what's going wrong. Here is the sample of my Custom Action
<CustomAction Id="RunExe" FileKey="Setup" ExeCommand="-switch" Execute="deferred" Return="check" Impersonate="no"/>
<InstallExecuteSequence>
<Custom Action="RunExe" Before="InstallFinalize">NOT Installed</Custom>
</InstallExecuteSequence>
The actual problem is that this .exe that is executed through ExeCommand is not able to access a registry key(HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders).
Running the msi as administrator solve the problem but i need a solution in which WIX should itself able to run the command as admin or atleast give a prompt to user.
A deferred custom action in a per machine install runs elevated with the system account. It's not clear what you mean by access to the HKCU key, but the HKCU key for an executable running with the system account is the system account's HKCU, not the installing user's HKCU. It would help if you said exactly what you are trying to achieve, because you might not need code at all. The install will update HKCU for the installing user if you use the registry features of WiX/MSI, so this may be a case of not really needing code at all.
It's also unclear why running the MSI as administrator solves the problem because that custom action will already be elevated in a per machine install with InstallPrivileges elevated. There is insufficient info in your post as tp your install context, but my guess is that you might be doing a per user install without InstallPrivileges elevated - that's one situation in which the MSI would run CAs under the installing user's account but they would not be elevated unless you elevate the entire install by doing as you said - runningthe MSI as administrator.
I have an Excel Add-in that uses a Wix (3.10) install script. The installation works fine. However, if the user tries to remove the add-in through System | Apps & Features, it fails with "There is a problem with this Windows Installer package. A program required for this install to complete could not be run." Looking at the uninstall log, I see this:
Error 1721. There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action: _BDF865EC_34B3_4B29_986C_98D6EC1A9807, location: C:\Windows\Installer\MSI2FE4.tmp, command: /uninstall="C:\Users\Windows10\AppData\Local\myCompany\myProduct\myAddin.dll" /privileges=user
The action that it is balking at is this:
<CustomAction Id="_BDF865EC_34B3_4B29_986C_98D6EC1A9807" BinaryKey="adxregistrator_exe" Execute="deferred" ExeCommand='/uninstall="[TARGETDIR]$(var.myProject.TargetFileName)" /privileges=user' Impersonate="yes" />
However, if I re-run my installer and select 'Remove', it uninstalls fine. Also, If I run the uninstall from a command line (using the msiexec command found in the registry entry for this product), it also uninstalls fine.
Also:
This only happens in Windows 10. Older versions of Windows are fine.
I have replicated on several machines, including a fresh install.
I have an older installer (a VS2010 Setup Project), the problem happens with that installer as well.
I have tried with UAC at different elevations, no difference.
I have seen other posts here about changing the Impersonate setting to "no", no difference.
It seems to me that there is a problem with the new Windows Apps & Features app, but I have yet to find anything on the Microsoft forums.
Update:
A Wix user posted this: DTF Bug with new Windows 10 Apps and Features. Also, we have tried a variety of commands (thinking it was a UAC issue), none of them work, even 'built-in' Windows commands fail.
I have run into the same issue and finally came with this solution:
Win 10 Apps & Features uninstaller checks for the WindowsInstaller registry value and behaves correctly when this value is not present
1) Define the custom action
<CustomAction Id="DeleteWindowsInstallerValue" Return="ignore" Directory="TARGETDIR" Execute="deferred" Impersonate="no"
ExeCommand= "reg.exe DELETE HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\[ProductCode] /v WindowsInstaller /f" />
2) schedule the action in the InstallExecuteSequence
<Custom Action="DeleteWindowsInstallerValue" Before="InstallFinalize"/>
Honza
I have created a MSI installer package using Wix Toolset 3.8 that is run by a third party installer service running under the "SYSTEM" account. My issue is that when trying to launch and run an installed executable from my MSI installer using a custom action, it also runs under the SYSTEM account instead of the administrator account that is currently logged in. I have spent hours researching on the net and from what I have read, specifying Impersonate="yes" will run that particular custom action under the account that launched the installer, but there lies the issue. Since the third party installer service is running from the SYSTEM account, specifying Impersonate="yes" would just run the custom action under the SYSTEM account as well correct? At least that's what my tests have shown. A little bit of background on my MSI installer:
InstallScope="perMachine"
<CustomAction Id="StartAction"
Directory="FOLDER"
ExeCommand ='cmd.exe /c start MYEXE.exe /tray'
Execute="immediate"
Impersonate="yes"
Return="check"/>
<InstallExecuteSequence>
<Custom Action='StartAction' Before='InstallFinalize'>NOT Installed</Custom>
</InstallExecuteSequence>
I have tried both "deferred" and "immediate" for Execute as well as setting "Impersonate" to both yes and no. Is there any way to make this work? I thought about using the runas command but I wouldn't know the password of the user account that initiated the install.
Thanks!
What is the EXE file doing? Do you have control of the application so you can move the logic from that external EXE into the main application's launching logic?
Other than that you can register such an EXE file to run once per user via ActiveSetup. You can also find another answer from me here.
Here is one more link to an explanation of ActiveSetup (I prefer the one above): http://www.ewall.org/tech/msi/self-healing
Also see these answer here: Stopping MSI from launching an EXE in the SYSTEM context
I'd like to create a standalone silent uninstaller using WIX that I can send to specific people for support purposes that can be double-clicked to execute the uninstall of our product when the uninstaller did not work properly on their machine and no longer exists (some users remove things manually using other tools). I have a .wxs file that uses the same product id and package id of the previously installed program, and if I run from msiexec /x it uninstalls the previously installed product perfectly. Double-clicking on it (which is all these users can be expected to do) however runs installation, not the uninstall. I tried adding
<Property Id="REMOVE" Value="ALL"/>
<Property Id="ACTION" Value="UNINSTALL"/>
and making sure all InstallExecuteSequence actions are not using an "Installed" check but the product is still installed after running successfully, the log file shows it is still executing ACTION INSTALL:
MSI (c) (A8:F8) [15:42:08:324]: PROPERTY CHANGE: Adding ACTION property. Its value is 'INSTALL'.
MSI (c) (A8:F8) [15:42:08:324]: Doing action: INSTALL
MSI (c) (A8:F8) [15:42:08:324]: Note: 1: 2205 2: 3: ActionText
Action 15:42:08: INSTALL.
Action start 15:42:08: INSTALL.
Is there a way to force an .msi file to perform an uninstall without using the command line or add/remove programs entries? I've seen entries about using ARPSYSTEMCOMPONENT but not enough information to do it.
I don't think so. You could, of course, use an exe to do it. I would also strongly suggest that you use the original msi file instead of creating a different msi with the same product code.
For the exe, you could use any number of chainer/bundler/downloaders. There is NSIS and also WiX's own Bootstrapper, ... even WinZip.
You should also note that many package management systems that run uninstall commands will run the install command first if anything is amiss. The theory is that an uninstaller can't properly run unless the critical data placed by installation exists. (E.G., WPKG). For Windows Installer, this usually doesn't apply since it's data is hidden from the user. But if they found it and corrupted it, reinstalling and/or repairing using a fresh copy of the original msi might do the job.