I currently use WIX (latest version) to package and bootstrap my Windows Form application.
I'm having an issue where my clients (using SOE workstations in a secure, enterprise environment) don't seem to have access to the MSI package cache directory when using the installer to perform a major upgrade. The installer completes successfully, but when they double click the desktop shortcut to launch the software, it displays the following two wix-generated dialogs:
I then get a 'Fatal error during installation.' message and the software won't open until it is completely uninstalled and reinstalled.
There are no issues at all with a fresh install. The current workaround is to manually uninstall old versions before installing the latest version.
I'm having trouble replicating this problem in my dev/test environments, and requesting my client to change their SOE configuration is out of the question.
Any advice would be most appreciated. I'm hoping there is a way to redirect the cache location to a UserData folder, or an entirely different approach to handling upgrades.
Thanks in advance for any guidance.
Related
We are creating a MSI installer for a windows application using WiX (and DevOps pipeline), which asks users (non-admin) to enter admin credentials to install it and updates on their machine.
However, now our objective it to not to force them entering admin credentials while installing the updates.
After going through some (old) articles, I came to know it is possible using patching, however, have not got any concrete examples.
Highly appreciate if someone can guide or give pointers or if there is a better alternative to patching.
Having an issue with WIX installer upgrade. Previously we had 2 version of installers 1 for per-machine and another for per-user.
Currently we have developed a dual mode MSI.
The dual mode MSI upgrades the PerUser version (on PC 1) of previous installer when install for yourself option is selected but when install for all (on PC 2 ) is selected it install a new product
Is it some wrong that we are doing or is have to set some properties. We are using WIX.
Please help
Per-user installs allow the installation of the same product multiple times for different users - and in different versions too. This makes upgrades and patches rather difficult to deal with, and I dislike this per-user concept altogether. I prefer to set the installer per-machine as standard. I don't feel that much is lost in functionality, but a lot is gained in managability. Though this is not an answer to your question, it is worth pointing out that per-user installs is a flawed concept - at best.
I don't know if it is an option to set your installer per-machine, but I found a way to migrate installs from per-user to per-machine automagically by using Installshield and its custom ISSetAllUsers custom action. The procedure is described here:
windows Installer - uninstalling previous version when the versions differ in installation policy (per-user, per-machine)
Wix does not feature such a custom action as far as I know, but you could write your own custom action using the Win32 API call ::MsiEnumRelatedProducts() as described by Rob Mensching here: how to change from per user to all user installation?
Here is a similar post for reference: How can a perUser installation program deal with a perMachine older version of the program?
Here is a blog describing (further) issues with per-user installs: Understanding “Per-User” or “Per-Machine” context for application Setup packages.
Let me add a couple of further comments:
You can have per-user settings without a per-user install. This is no problem, just have the application set up the userprofile on launch. I prefer to install all resource files and settings per-machine and have the application copy them to each user for first launch initialization. This ensures that user settings are not entangled with your MSI at all.
It is rare to maintain two separate versions of the same product at the same time - hence users are all likely to use the same version of the product. Per-user is just more headache in this perspective.
The upgrade and patching logic involved in per-user installer scenarios beats me - it just doesn't make any sense to me. If there is a per-machine install already, does a per-user install make sense to you? Does this install the application one more time?
If per-user installs are still important, perhaps you can try ClickOnce (if it still works). Quote from Wikipedia: "...ClickOnce-deployed applications are considered 'low impact', in that they are installed per-user, not per-machine. No administrator privileges are required to install one of these applications. Each ClickOnce application is isolated from the others. This means one ClickOnce application is not able to 'break' another.". Per-user installs make more sense if they are hooked up to auto-updating and web-deployment.
If you had two setups before, it might be that you have two upgrade code and need to deal with both for the upgrade to work in all cases?
It has been a long time since I dealt with per-user stuff, but in general you must author your Upgrade table to include both upgrade codes for your setups to detect all flavours of your previous install. The upgrade table allows you to detect any number of prior installs that should be scheduled for uninstall before your new product gets installed.
The FindRelatedProducts MSI action will search all packages on the target machine in order to find any where the Upgrade Code property matches the value specified in the upgrade table.
Make a verbose log file as has been suggested:
msiexec.exe /I "File.msi" /QN /L*V "C:\Temp\msilog.log"
/I = run installation sequence
/L*V "C:\Temp\msilog.log"= verbose logging
/QN = run completely silently
I believe this is occurring because in your installer the default mode is Per-User hence it is not detecting per-machine.
You could use MSIGetProductInfo to find the installed products if the assignmenttype is “1” then you could set the below properties to Product Code of Per-Machine product
WIX_UPGRADE_DETECTED
OLDERVERSIONBEINGUPGRADED
Use a custom action on button click or schedule it after FindRelatedProducts.
This tells the installer of an existing version and installation is handle like an upgrade.
Windows Installer does not upgrade between per user and per machine, or vice versa. If you want this to happen you need to get in front of the install somehow and find out what type is already installed. Trying to do that when the product has been installed for another user (i.e. not the current installing user) is tricky. MsiEnumRelatedProuctsEx can be called a couple of times looking for per machine and per user installs to see what's going on. However there may be issues with you, User A, trying to uninstall a product that was installed per user by User B. If you are the same user it's easier. MsiEnumRelatedProductsEx can be called a couple of times to see if the product is per user or machine (in a launcher maybe) and you can uninstall the product before installing the new upgrade, or at least tell the user to do the uninstall. Anyway, it can be a mess, and the advice to stick with per machine installs is worth taking.
I should also point out that allowing per user AND per machine installs on the same machine is a feature, not a bug.
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 have an *.msi installation that uses Wix Extensions :
WixFirewallExtension (To create firewall exceptions)
WixNetFxExtention (To create Native Images at install time)
This msi fails with the error "Installation ended prematurely..." when attempting to install on Windows Server 2003 (both 32 and 64 bit). It installs on Server 2008/Windows 7 etc with no issue.
Removing the firewall and native image parts before building the msi allow it to install normally but obviously without the extra options in place.
Does anyone know what the issue could be?
Here is the part of the log file that shows the failure but it doesn't say why it failed.
Other Notes:
Removing the firewall part but leaving the native image part still causes failure which is causing me to believe that any operation that uses an Extension will be affected.
The firewall configuration is set to ignore failures.
I have confirmed the firewall is enabled and running.
I have tried installing from an Administrator command prompt but this makes no difference
It sounds like a bug in the WiX v3.8 toolset. There were issues in earlier builds where the new VS2012 compilers did not support Windows XP. That was fixed in WiX v3.8.422.0 or newer. If you are not running the latest build of WiX v3.8, I recommend upgrading and seeing if the issue is fixed. If you are running the latest build of WiX v3.8 then you might open a bug: http://wixtoolset.org/bugs.
I have been using InstallShield LE in Visual Studio 2010, but it is heavily limited and sometimes buggy. I looked at paid InstallShield versions, but these also have too many limitations for that price tag.
So I decided to switch to WiX. I have had some experience with it some years ago. It was pretty easy to build a simple installer using SharpDevelop with WiX tools.
Now I am trying to collect solutions and tools for WiX. Basically, I need to get the following functionality (requested by my client):
when I launch the installer, it should check a text file on the server and see if a newer version is available. If it's the case, then the installer should be able to download the updated installer package and launch it (are there any downloader utilities in WiX?)
solving dependencies. Major dependency of my app is .NET 4 (which itself depends on Windows Installer 3). The installer should offer the user to download and install them automatically
logging the installation process, also collecting the log file of the dependencies' installation process. I don't want the user to hunt various .log files in case .NET4 or WindowsInstaller3 installation fails. All the information should be collected in one place and if something fails, I should show the user a custom popup dialog with an option to save the complete install log file and send it to me
installer should be able to detect if there is a newer version of my app already installed, and show a meaningful customized error message before it exits
installer should be able to detect if there is an older version of my app already installed. and offer the user to exit installation or uninstall the previous version and install the new version. BTW, there are no minor component upgrades planned, I prefer to reinstall everything fresh (I guess, this is a major upgrade in the terms of WindowsInstaller). Installshield LE failed on me for this, it just showed an error box with the message about another product, but did not offer to uninstall it
in case of an upgrade, installer should be able to detect if some of application components are in use (running application processes) and show a custom error message and not just some cryptic "Installation failed"
I have read that it may be a bit painful to manage upgrades even if I keep my UpgradeCode intact, because this code is stored in the Windows Registry in a compressed way and also if the user renames the downloaded file, it might get detected as a completely new product by WindowsInstaller ... or maybe this is only the case with WindowsInstaller .msi files and WiX has some trick to avoid this issue?
About update downloading - I need this functionality also in my application itself. I am not sure how to implement it efficiently, so I can reuse the same update downloader code/utility in both WiX installer and in my app.
Is it possible to satisfy all these requirements using currently existing WiX tools, or maybe I'll need to code some components from scratch?
WiX is definitely the way to go in my opinion.
when I launch the installer, it should check a text file on the server and see if a newer version is available. If it's the case,
then the installer should be able to download the updated installer
package and launch it (are there any downloader utilities in WiX?)
In my opinion, this type of functionality is best handled by the application. However you can implement such functionality in a custom bootstrapper. The latest development of WiX includes a bootstrapper engine Burn that allows you to write your own custom bootstrapper on top of it.
solving dependencies. Major dependency of my app is .NET 4 (which itself depends on Windows Installer 3). The installer should offer
the user to download and install them automatically
You can use the standard WiX bootstrapper to install .NET as a prereq. Or if you create your own custom managed bootstrapper application, you can install .NET a prereq to your bootstrapper as in this example
logging the installation process, also collecting the log file of the dependencies' installation process. I don't want the user to
hunt various .log files in case .NET4 or WindowsInstaller3
installation fails. All the information should be collected in one
place and if something fails, I should show the user a custom popup
dialog with an option to save the complete install log file and send
it to me
Using the two bootstrapping methods above, when you launch your msi you can specify parameters for logging. In my own custom managed bootstrapper I created a button to open the log files created during installation.
installer should be able to detect if there is a newer version of my app already installed, and show a meaningful customized error
message before it exits
You can do this using launch conditions
installer should be able to detect if there is an older version of my app already installed. and offer the user to exit installation or
uninstall the previous version and install the new version. BTW,
there are no minor component upgrades planned, I prefer to reinstall
everything fresh (I guess, this is a major upgrade in the terms of
WindowsInstaller). Installshield LE failed on me for this, it just
showed an error box with the message about another product, but did
not offer to uninstall it
In my experience this major upgrades are the least complicated
approach.
in case of an upgrade, installer should be able to detect if some of
application components are in use (running application processes) and
show a custom error message and not just some cryptic "Installation
failed"
I think WiX/Windows Installer are generally good at handling these
scenarios and automatically notifying the user that
files/applications need shutdown without you having to author
anything extra in your installer.
All that said, you may want to look into creating your own custom managed bootstrapper using WiX and Burn. That is not trivial however. The best place to go is to download the source code to the WiX Weekly Releases and checkout the project src\Setup\WixBA. It is the custom BA that they wrote to install WiX. There isn't much documentation out there yet because WiX 3.6 is not released (although it is pretty stable). However you don't have to create your own BA to make a solid WiX installer that can handle upgrades and logging.