On my test machine, the setup installs/uninstalls without any problem.
Also, I already have installed about 50 customers with this installer.
It seems to be only my installer that has the problem (tried to install example msi, which worked)
I tried the Microsoft Fixit tool for fixing corruption issues.
I tried MsiZap from the windows development toolkit
I tried searching the registry manually for leftover keys ...
Nothing worked.
Does anyone know exactly what this error means, and I mean by that, what does it check (registry key? ...) to respond with this error?
One possibility is that somewhere in your WiX you have something like a WiX util CreateUser and it's trying to create a use that already exists. If so, then using UpdateIfExists might be appropriate, or setting FailIfExists to no, or just manually deleting that user from the system.
If it's more complicated than that, this may help (your question appears to be a duplicate of this):
Windows msi: error 1316: the specified account already exists
and this appears to fix some Windows issues in this area:
https://support.microsoft.com/en-us/mats/program_install_and_uninstall/en
Related
I have a custom bootstrapper (C# WPF) and it works well enough. If the installer gets run from the command line after it was installed, it brings up a window allowing the user to select if they want to modify, repair or uninstall. So far so good. Modify mode starts the UI which ends up calling Bootstrapper.Plan(LaunchAction.Modify). The problem is that if I call it from the launcher UI it immediately complains that a prior install requires a reboot.
I have not found any good examples on what this should do. Even the WiX mailing list came up blank.
Any ideas?
It would be helpful with the screenshot for that reboot message - just to get a feel for where it might be coming from and to get a literal string to search for. Did you have a look in the WiX source code yourself btw? (WiX 3.111 branch)
I started writing a lot of stuff about reboots. Not good. Maybe just some questions instead:
Does this happen every time you invoke modify and is it reproducible on more than one computer? Or maybe it is just Windows Update acting up on a problem computer?
I assume you have rebooted the computer where you see the problem and you see the problem again when you re-launch the bundle?
Do you schedule any reboots inside your MSI files during the initial installation?
Either using the ScheduleReboot action or a custom action which schedules a reboot with a call to MsiSetMode (for example)?
There is a long explanation here why such reboot-constructs cause problems, but that may be besides the point. Essentially badly configured reboot-constructs can trigger spontaneous, unexpected reboots without warning when packages are run in silent mode (plus other problems).
Could you try to run the test VBScript found in this answer: WiX behaving badly on XP machine with windows update issues in order to check if the script reports a reboot being necessary?
Other than that I guess you could try to run Burn yourself in debug mode (not sure how much plumbing that would be to get running) or perhaps first try a ProcMon.exe session to see if you can see something obvious. The latter should be quick to do?
There are some registry locations you can hunt down to see if you can figure out what triggered the reboot warning. Get-PendingReboot-Query. And a similar PowerShell script.
So in the end it was user error. :-( O well. I did learn a lot about how to figure out how Windows checks for the need to reboot etc.
The issue was simple in the end. During the modify run it was uninstalling, then reinstalling a number of services. The problem is that when it runs (seeing as you have to set it to repair to get it to work) it copies all the files again and the services were still running at the start of the install. The fix was to uninstall anything that might lock a file before the actual file copy starts and that solved the issue for me.
Thanks for your help guys, all the info helped me look in different directions until I found the issue. Awesome community as always!
The Setup
So I have a Custom Action in my InstallExecuteSequence that looks like this:
<Custom Action="UpdateConfigFile" After="InstallFinalize">NOT Installed OR Upgrading</Custom>
Where Upgrading is defined to:
<SetProperty After="SetFirstInstall" Id="Upgrading" Value="true">
WIX_UPGRADE_DETECTED AND NOT (REMOVE="ALL")
</SetProperty>
The Custom Action updates a web.config file with a value that is passed into the installer via a Property. It is a VB.Net function.
The Issue I'm Running Into
This Custom Action has always executed in many of our installers. But for a certain environment that we have in development, the conditions for it resolve to False on a install/upgrade scenario. It says "(condition is false)" in the MSI log.
The environment is used for development purposes such as testing the product after installed/updated.
What I'm Trying to Accomplish
I would like this to be resolved so that this environment can install our product successfully.
What I've Done So Far
I've installed the same installer to different Operating Systems such as Windows 10, 2012 R2, and 2016. The installer works just fine since the Custom Action runs as expected.
The troublesome environment is a Windows Server 2012 R2 machine. Which makes me even more confused.
I did some digging in and was only able to find this link: (https://blogs.msdn.microsoft.com/heaths/2006/07/11/why-a-custom-action-may-not-run/#comments)
From the link's suggestion, I think it is really odd if a dependency was missing because the same installer works on other machines.
So I'm pretty stumped at this point. Any help or direction would be very much appreciated. If I'm not being clear enough, feel free to ask for more clarification. Please and thank you.
Just some comments to get going, this isn't a real answer:
First things first: in order to be passed properly to deferred mode (InstallExecuteSequence) properties should be UPPERCASE (public properties) and they should be listed in the SecureCustomProperties delimited list of "safe properties" to pass to deferred mode.
Other than uppercasing it, I wouldn't set a property called Upgrading like that, I would rather use the "raw" conditions for the custom action in deferred mode (InstallExecuteSequence).
Here is a cheat sheet of common conditions from Flexera (makers of Installshield): Common MSI Conditions Cheat Sheet. And here is a direct link to the PDF.
You can have a look at this old post: How to add a WiX custom action that happens only on uninstall (via MSI)?. I have never had the time to test all those conditions, but at face value it looks correct.
Some notes about the special property UPGRADINGPRODUCTCODE.
UPGRADE:
Questions:
That Windows Server 2012 R2 machine - is there anything special about it? Is it tightened for security? What is its task or purpose on the network?
What is the actual implementation of UpdateConfigFile - is it a script, a compiled DLL written in C++, a managed DLL written in a .NET language, or something else? Maybe an EXE file?
Does any of this sound familiar: Installer fails on Windows Server 2012 R2
Did you verify that the correct version of the .NET framework is installed on this problem server? Does the function run interactively? Try running that VB.NET function interactively on that computer via a test harness EXE if it is a DLL function. Or just run it straight is it is an EXE file outright.
The issue is likely to be that you are scheduled after InstallFinalize (which is not good, see later) because the Upgrading property is not public (not uppercase). If you change the condition to WIX_UPGRADE_DETECTED AND NOT (REMOVE="ALL") it should work, assuming:
WIX_UPGRADE_DETECTED is the actual property associated with the major upgrade, such as from the major uypgrade element.
WIX_UPGRADE_DETECTED is in SecureCustomProperies.
Actions after InstallFinalize are generally not recommended because if they fail (in your case screw up the config file) then there is not much that can be done (such as roll back to a correct config file). It's effectively after the install, so it's also easier to do the config changes in the app when the upgraded version runs for the first time.
After helping the team responsible for the environment, we found out that it was a certain scenario that was causing this issue. Digging deep into the MSI log further, we found that a previous Custom Action running, also after InstallFinalize, was returning a Failure Action Result. Since that happened, the following Custom Actions such as my UpdateConfigFile Custom Action, don't execute. Resulting in the "(condition is false)" entry in the log.
Once we figured that out, I was able to reproduce it on my local environment.
Since these Custom Actions are after InstallFinalize, I thought that those Custom Actions would still run if one failed because we're past the point of the installer being able to do a Rollback. But I was wrong and now I know.
Thanks for everyone helping me out in trying to figure out this issue. I was getting worried that I was going to try to figure this out for days and start pulling my hair out. XD
I ran into an issue that when my custom action fails during an installation that an ARP entry is still created for the bundle. Is there a way to remove that ARP entry from Add/Remove programs? Or is this the expected behaviour?
Thanks!
This tool from Microsoft will attempt to fix failed installation/uninstallations that still appear in the add/remove programs list.
The issue is related to orphaned or incorrect registry entries. There are a lot of references to other keys though so if you aren't thorough doing it yourself you can leave something behind that might bite you later on.
This tool is probably the safest way to fix your registry with regards to installations but it is not 100%
https://support.microsoft.com/en-ca/help/17588/fix-problems-that-block-programs-from-being-installed-or-removed
Bundles are registered to manage reboots and repair and the registration is not removed if any package in the chain was successful.
I am trying to build a WIX installer MSI Package. While installation process I am doing some registry entries which needs reboot to take effect..
Well my question is,
How to reboot on 1st time/fresh install (not on upgrade) and that to without using custom actions? (custom actions are restricted by several AntiVirus programs, well that's another story)
I have tried ScheduleReboot After='InstallFinalize' with several conditions like :
NOT REINSTALL, REMOVE="ALL", NOT UPGRADINGPRODUCTCODE, NOT INSTALLED.. but still it's rebooting always, And I also have checked that if I remove
Thanks
NileshV
It's possible that Windows wants to reboot anyway - if that's needed it will happen, so you first need to be sure that it is not rebooting by skipping the ScheduleReboot completely. As Chroistopher points out, if you're not setting the REBOOT property then Windows will reboot you anyway.
The condition you want is Not Installed. Unfortunately property names are case sensitive and your spelling of INSTALLED is wrong.
Has anyone managed to install CLisp on Windows 8. I am unable to get it to work. I downloaded the exe from SF. But, after I allow the application to run as administrator, I see nothing. I did notice that I was unable to delete the file. So, I suspect that there is a prompt that I'm not seeing. Any ideas?
Eureka!
I think that I found it. I was able to install it. I suspect that the installation windows being sent to another session. My daughter was signed on while I was working on this (over several days). After a slow reboot (Thank you Microsoft Update), it worked as expected. I would classify this as an I-D-10-T error except that I think it was reasonable for me to see the dialog regardless of whether or not another user was signed in. Thanks again to all of the commenters.