I want my installer to prompt the user to uninstall an existing installation before installing the new one if an installation already exists at the selected install directory.
Right now I'm trying to just call the uninstall dialog and let it continue its normal execution from there, but since it is already in the install sequence, it continues to run functions for installing, rather than uninstalling.
Is this even possible to do? And if not, how else might I accomplish the same thing.
I'm using a Basic MSI project, and due to the nature of my installation, I don't believe I'll be able to set up a Major upgrade.
Related
I am attempting to make sure certain software does not exist before installing the newer version. Long story short, vendor requires me to do so, and although they recommend me to repair after install, that causes other issues such as undesirable restart (trust me I tried /norestart and I have even tried to modify the stored msi package to make sure it does not restart) but over all it just gives us soo much headache without the result we want.
So I tried to simply uninstall this software ahead of installing their newer one since that seem to have higher success rate without unnecessary issues.
Now I am accomplishing this by running batch file via ExePackage (with WiX toolset) with Vital="no". I have to do Vital="no" because when the older installer does not exist and if I call msiexec /x, it returns the error stating
this action is only valid for products that are currently installed
When the older installation exists, it works fine, but when it does not it errors out.
Now Vital="no" works fine, but I would prefer to suppress the error with msiexec /x if I can.
Is there any known way to solve this?
In order to solve this problem, I checked the uninstall keys and only called msiexec /x on products that were listed. Though in my own case, we were switching installer tech (too many MSI bugs...) and were uninstalling older versions of our own.
Installation State: You can use VBScript to check for the installation state of a product if you know its product GUID (replace the sample GUID here):
Dim installer : Set installer = CreateObject("WindowsInstaller.Installer")
MsgBox installer.ProductState("{6C961B30-A670-8A05-3BFE-3947E84DD4E4}")
There are a number of possible installation states. Here is a more comprehensive script to check product installation state. Check section 7 here.
Major Upgrades: I assume you are aware of how major upgrades work? (uninstall of existing installation and install of newer version with options for what order this happens in). They can in reality uninstall any other MSI package on installation via settings in its Upgrade table. This includes even competitive products (a bit mad one would have to say). You can - however - not install them again easily from within MSI for a number of technical issues. You could install them via a Burn setup.exe bootstrapper (which I think you use).
If I execute a Wix installer for first time it will install as expected.
If I re-run the installer it correctly enters maintenance mode (Repair/Change/Modify)
However if I re-compile the installer between the initial install and the re-run, it treats it as new installer. I have tried using the same Product Id but when the newly compiled installer is executed, I then get a message saying it has already been installed and must un-install the previous version.
As part of our development I am trying to resolve some issues with the Maintenance UI and don't want to have to run the installer twice every time I wish to debug the maintenance wizard. I would like the re-compiled installer to be treated as if it were the original installer.
Thanks for any pointers you may be able to throw at me, or other suitable resource
Technically this is not something that you should do. By rebuilding, you are altering the package, which means it is supposed to have a new package code. When it has a new package code, but matching product code and version, it is a small update. You can skip the uninstall and install by instead performing a reinstall via msiexec /fvomus your.msi or msiexec /i your.msi REINSTALL=ALL REINSTALLMODE=vomus.
As another approach, if what you are testing doesn't depend heavily on machine state, you can tweak some of the entry conditions for the maintenance UI such that it occurs on a first-time installation, and ensure that the package cannot install. This puts you in a simpler reproduction loop, but will require transplanting your finished code back to the real scenario.
I am using Visual Studio 2013 installer to package my application. I then make a copy of the MSI, open it in Orca and remove all the dialogs to create a silent package. So I have two MSI's that should be the same other than one is silent and the other is not.
When I upgrade from a previous version (built in the same way) using the non-silent package, everything works perfectly.
However when I upgrade from a previous version using the silent package, it all works apart from I am left with 2 entries in Add/Remove programs. It all works though but looks ugly for the client. When i uninstall the latest version, Add remove programs still has the previous version listed in Add/Remove programs although actually the latest version is still installed.
As I say, the non-silent package works perfectly well, which leads me to think I must have everything setup correctly in Visual Studio and Orca must be doing something I didn't intend.
Any help would be much appreciated.
If you have two entries in Add/Remove Programs then the upgrade didn't work. A common reason is that one of the installs is Everyone and the other is Just me. If you delete the dialogs then you have altered the behavior that sets the ALLUSERS property, and your upgrade could default to Just me. In the absence of a decision to use one of these choices VS setups use ALLUSERS=2 which is defaulting to a per user Just me install, that's the likely reason. Elevation is involved too - VS setups would rather your MSI did a successful Just me instead of a failing Everyone if privilege state is not clear (and in MSI setups it often isn't).
You might need to go to the Property table and set FolderForm_AllUsers to "ALL" and ALLUSERS to 1 to force a per machine Everyone install.
How silent do you want it to be? If it requires elevation to install successfully then you need the elevation dialog to be shown or the install will fail silently if you force a per machine Everyone install.
I have created my application's setup in installshield - basic MSI project...
Now when i am installing it, it allows me to run .exe multiple times simultanious...
Please let me know, how can i stop it.....
There is already a safe guard automatically built-into Windows Installer. If two or more of your installs actually try to install only the first one will install. The others will throw a message saying another install is already in progress. This is enforced by the _msiexecute mutex.
If you want to gate the situation earlier, you'll have to write your own custom actions to create your own custom mutex, tear it down when the install is complete and check for it when starting the install. However, I'd mark this problem as Functions as Designed and move on.
We are using VS2008 native Installer to set up our product. During both installation and product removal, we use Custom Actions to ask the user if he would like to keep his existing DB and settings (if detected).
The arises when the user is upgrading: the Installer starts, recognizes there is a previous version installed, and calls the UnInstaller first. So the user is thus presented with the same Q twice - once during the uninstall of the previous version, and again during installation of the first.
Is there some way to "let the uninstaller" know that it is being called as part of an upgrade, so we can bypass one of the questions?
I'm not sure about the specifics of VS2008, but if you're generating an MSI package you can schedule display of the dialog based on the UPGRADINGPRODUCTCODE property - this is automatically set during an upgrade with the product code of the package that is being uninstalled.