I've created an installer with Wix Toolset 3.11 that installes a web site in IIS using Wixs IISExtension.
I install the MSI and everything looks good so far.
Now I uninstall the IIS role while the MSI is still installed. (did this for testing purposes)
Problem: The MSI now cannot be uninstalled anymore. The uninstallation fails, as it cannot make changes to the IIS config anymore. It's throwing errors in the uninstall.log regarding this, performes a rollback of uninstall and leaves the application installed.
In my opinion this should be a corner case, but does anybody know some kind of switch or workaround to ignore these errors and continue with the uninstallation? Any help appreciated.
Regards
This is a scenario that is well known so I'm surprised your getting this. It Condition (LaunchCondition) elements we always say...
SOMETHINGTHATISREQUIRED and Not Installed
...so that the REQUIRED is evaluated during initial installation but not subsequent transactions including uninstall. Looking at built MSI the custom action condition is
NOT SKIPCONFIGUREIIS AND VersionNT > 400
I'd think a condition could be made that verified IIS was still present or maybe the custom action code could do a try/catch best effort. Maybe the decision was made to not do that because it could leave traces behind and result in a dirty uninstall.
So you can document msiexec /x yourproduct SKIPCONFIGUREIIS=1 and you'll be able to uninstall.
You could open an issue with WiX. My guess is they will answer it's by design.
Related
There is windows installer based on Wix which is not implemented correctly and it has several custom action that should not be executed in uninstallation (msi & msp).
I'm going to add custom action to restart system (by using powershell) in the middle of patch uninstallation process (windows installer uninstalled everything). It looks like the process finalized successfully and the patch uninstalled and application works fine.
Are there any risks to do it?
Are there any flags to set in wix file to resume uninstallation after rebooting?
This sounds potentially dangerous - not sure what happens to MSI when you force reboot out of the blue (there are standard ways to invoke reboots instead).
Generally you should be able to fix anything wrong inside the MSI by patching it with a minor upgrade first and then run the fixed uninstall sequence. (this is because the installation of a minor upgrade does not trigger the existing package's uninstall sequence): MSI cleanup approaches (for broken uninstalls) (older answer).
Is there any reason why this approach would not work? Then you should not need any dangerous rebooting, but let Windows Installer do the rebooting itself.
There are advanced features to deal with reboots in MSI, but it is never a good thing to invoke (undesired complexity) and it needs lots of testing. Avoid if you can. You can call the ScheduleReboot action with proper conditioning and the MSI will trigger a reboot warning or a direct reboot if run in silent mode.
Please provide more details of what is happening in your setup.
I am having an MSI file which copies a set of dll from it source to destination folder. While running the MSI the dll are copied to the destination folder also the MSI is installed in the system. I can see that in ADD or REMOVE programs.
Whenever there is a change in dll, i copying the new dll and building the MSI again. When i tries to run MSI in the same system i am getting error "Another version is already. Uninstall that version and proceed" something like that.
What i am doing until now is uninstalling the old one (MSI) and installing the new one.
But i want the MSI to update the older dll with the latest dll from the MSI instead of uninstalling and installing again.
Thanks in advance.
You can't just rerun the MSI to do an update. There's some background here, even if you are not using Visual Studio setups, and it's still relevant after all this time:
https://www.simple-talk.com/dotnet/visual-studio/updates-to-setup-projects/
To replace a single file, build a patch, an msp file. To upgrade the entire setup, including that Dll then use the WiX majorupgrade element, and that may be a lot easier than building a patch, especially if your setup is small and doesn't take long to install. Increase the file version of the Dll to make sure it gets replaced.
welcome to StackOverflow - it seems to be your first post. I would read this thread if I were you to get an overview of how to implement a WIX major upgrade: How to implement WiX installer upgrade?. Here is another thread (didn't read this one through): How to get WiX major upgrade working?
A major upgrade is essentially an automatic uninstall of the existing version and reinstall of a new version. This is the least error prone update mechanism in Windows Installer. It is the recommended approach to try at first - it works well. A minor upgrade - which is upgrading the existing install, is generally more difficult to get right in the beginning. A number of technical restrictions apply. Here is a very good summary of what is required for a minor upgrade to work (as well as other details): http://www.installsite.org/pages/en/msi/updates.htm
Check out this well known wix tutorial for upgrades and patches. And MSDN.
I'm trying to certify a desktop application for Windows 8.1 using Windows App Certification Kit 3.1.
Everything is fine with the exception of the uninstall. I created the MSI file using Wix Toolkit 3.6. When the application installs it creates an entry in Programs and Features as well as a shortcut for uninstalling.
When I trigger the uninstall from either of these locations it works properly and all the files and registry entries get removed.
However, when the WACK launches the uninstall process, the MSI starts the installation process instead.
Is there a specific command from msiexec I need to test that WACK might be using to cause this?
I really do not understand why the Kit will launch the installer again.
Thank you,
Fernando
I found the problem and my solution.
The WACK calls the uninstall process using the Change option instead of Uninstall. You can test this by going to *Programs and Feature*s and clicking Change.
Since my application does not support changing or repairing, I simply set ARPNOREPAIR and ARPNOMODIFY to "Yes" and now WACK only calls uninstall.
The other option is to offer the Change/Repair dialog on your setup project and have the Remove check-mark available.
Hope this helps.
Cheers,
Fernando
I'm struggling with my Custom Bootstrapper Upgrade issue. By following this thread, I'm using LaunchAction.Install.
This does Upgrade the Product as well as Boostrapper, but older Bootstrapper remains there, as shown in following screen shot.
If I invoke ver 1.0.0.0 from here, it would display Dialog to Install, but would do nothing. However, invoking ver 1.0.1.0 would give me the option to Uninstall the product. However, upon Uninstall, it would only remove itself, and "My Product" is left behind.
I also tried with
_bootstrapper.Engine.Plan(LaunchAction.UpdateReplace);
and
_bootstrapper.Engine.Plan(LaunchAction.UpdateReplaceEmbedded);
but it has no effect.
Question: How to upgrade older installation without falling in above situation? Can anyone please provide a working example of CustomBA upgrade?
Regards
Check the PlanRelatedBundle event. Its where you can tell the Engine what to do with the old bundles.
If you want a Bundle to replace the old one the UpgradeCode should be the same for both. In this case it will uninstall the old bundle as default.
Also the old bundle needs to support quiet uninstallation since it will be called with the argument /quit after installing the new one.
You can check it in the BootstrapperApplication.Command.Display property. It should be "Embedded" if its called from another Bundle. The BootstrapperApplication.Command.Action is set to "Uninstall" in this case.
If nothing of this works check the logs that are created in the AppData\Temp folder.
I also experienced this problem. I had to write my own managed bootstrap application. I had a bug where I was kicking off the Plan() phase before the Detect() phase finished.
Hence the old bundle was not uninstalling as it should have.
It is good practice to implement a handler for every event that the Bootstrapper offers. Write a log entry in every handler listing out the arguments supplied to the handler. It makes chasing down errors a lot easier.
In my case I was migrating from InstallShield 2009 to WiX 3.10 and I had to write my own managed bootstrapper because I had to conditionally install SQL Server express based on user inputs from a fancy WPF boostrapper.
I've developed a Wix installer for an internal project however entirely by accident I've found that I'm unable to uninstall the installer on my development machine as I get the following error message:
The feature you are trying to use is on a network resource that is unavailable
with a dialog pointing to the path of the .msi that I installed from feature from. (The .msi is there, however is has been rebuilt and so has changed since I installed it)
I'm concerned by this dialog as I had believed that Windows Installer kept track of installed .MSI files, however this dialog seems to suggest that I can break my uninstaller by deleting, moving or changing the installer.
Is this the case?
What do I need to do to make sure that I don't break my uninstaller in this way? (Do we need to keep copies of all versions of the installer ever installed on a machine?)
The easiest way to get out of this situation is to do a recache/reinstall. Build a new version of your MSI that isn't "broken" (in whatever way it is broken, in this case, it might not really be broken at all, you just need a new source). Then you use a command line like:
msiexec /fv path\to\your.msi /l*v i.txt
That will copy your.msi over the MSI that is cached and do a repair. Then you'll be in a better place.
One of the first painful lessons of writing installs is to never run your install on your own box. Certainly not until it reaches a point of maturity and has gone through several QA cycles. This is what we have integration labs and virtual machines for. (There is a saying about things you shouldn't do in your own back yard.)
That said, normally an MSI uninstall doesn't require the MSI but there are situations where it could be required. For example if one was to call the ResolveSource action during an uninstall, MSI would then look for the .MSI.
Now there are several ways out of this pickle:
Take an MSI you do have and edit it with ORCA to match to file name, UpgradeCode, ProductCode and PackageCode of the MSI that you installed. You should be able to get all of this information from looking at the stripped cached MSI that exists in %WINDIR%\Installer. CD to that directory and do a findstr -i -m SOMESTRING *.msi where SOMESTRING is something unique like your ProductName property. Once you know the name of the cached MSI, open it in Orca to get the required attributes. Then put these attributes in a copy of the MSI you have available and try to do an uninstall. No, it's not the exact MSI that you installed but usually it's close enough.
or
Use the front end windows installer cleanup utility (if you still have it) and/or the backend MSIZAP utility to wipe all knowledge of the application from MSI and Add/RemovePrograms. Note, this doesn't actually uninstall the program so you'll have to also write a script or otherwise manually uninstall all traces of the program.
or
Reimage your workstation
If you know exactly what is wrong (which is often the case during development), I prefer to open the MSI file that Windows will use for uninstallation and edit it directly with a tool like Orca to fix or remove the part that causes the failure.
For example:
Locate the MSI file in %WINDIR%\Installer. The MSI should be the last edited MSI file in that folder right after you did the failed uninstallation.
Open the msi file with Orca.
Remove the failing part - for example the InstallExecuteSequence action that fails which is atypical scenario.
Save the msi and close Orca to release the lock on the msi file.
1 - Have you experimented with "run from source" during installation?
This is an option in the feature tree which allows you to run some files from their installation source. This is generally combined with an admin image on the network. See image below. I haven't tried it, but I assume this could cause: "The feature you are trying to use is on a network resource that is unavailable" if the network is down and you are trying to uninstall. Just a theory, there are other ways this could happen.
2 - Are you running script custom actions? If so, do you extract to the tmp folder or run from installed files or the binary table? If so, is the custom action conditioned to run only on install?
3 - Are you perhaps running an EXE custom action that is pointing to an installed file? If so this file may be unreachable on the network.
4 - Are any of your userprofile folders redirected to a network share?
5 - Are you installing anything directly to a folder on the network?
There are plenty of other possibilities.