I have a WPF application which I develop. Its Setup is InstallShield 2013 LE project.
A clean install is fine. However, when I REBUILD my setup and run it again, it shows error "Another version of this product is already installed".
What I want is when I run Setup again, installation is FORCED with no regard to what version (might be) already installed.
P.S. Upgrade paths were suggested, but don't seem to affect the setup behavior. The setup version isn't changed between rebuilds, it's all the way 1.0.0, the same product and upgrade code.
The whole idea is to reinstall and reinstall, until development is done, just like in continous integration.
The solution is to run
msiexec /fva Mixed.Studio.msi
prior to running actual setup of the product. The code above runs smoothly with no regard to is the product installed or not.
The code forcefully replaces stored MSI with the new one, which takes away "Another version..." message. More than that, even if the user cancels setup, it still can later do "Restore" from Control Panel, and by doing that new version will effectively be installed.
Related
I have my project in visual studio and i am using installshield as my windows installer. When I am installing new updated version of my application it will shows
Another version of this product is automatically installed like this...
How can I install new version by overwriting my old version?
Is there any way to configure in installshield or give me any other way
?
The error that you're getting is because the ProductCode has not been changed. This code is what makes your product/installer unique. Generally to author the upgrade you'll need to change this code and make sure the UpgradeCode is the same so that it recognizes what is already installed.
Authoring upgrades is a much wider topic and far too much information then can be covered here. I would suggest this page for learning about Windows installer upgrading.
Every upgraded version of install should have a different ProductCode. UpgradeCode is what tells the install package that this product has been installed. If ProductCode is also the same, install assumes you are installing the same product again. ProductCode needs to be different for each of the updated packages.
Under The Upgrade Paths, create a new path. Leave the min version blank (unless you need it), include min version yes, Max version should be set to the version You are installing now. Include max version to yes.
Each time you are installing an update, Increase the Product version(If u want to change) in the General Information section. Click on a new Product Code in the General Information Section Do not change the upgrade code.
Go back to the upgrade path, and set the Max version to the same version you are deploying now.
And make sure the Upgrade code in the "General Information" and "Upgrade path" are same.
This process uninstalls previous version, and installs the latest. No duplicates in add/remove programs.
If any doubt on this, comment your question...
I have upgraded a shipping Windows Desktop application from version 6.0.15.0 to version 6.1.0.0. I am using the Limited Edition of InstallShield, with Visual Studio 2013, for the installation program. Upon running the installation program on a PC that has version 6.0.15.0 installed, the installation program says "Another Version of this product is already installed"
I set the Product Version to "6.1.0.0." in the upgraded version. I did not change the product code or the upgrade code GUIDs (from version 6.0), because the documentations says not to change them. The documentation says,
"Because the product code uniquely identifies your product, changing the code after distributing a release of your product is not recommended."
"The upgrade code, stored in the UpgradeCode property, should remain the same for all versions of a product."
What must be changed in the InstallShield Visual Studio project to enable it to replace 6.0 with 6.1, without a need to uninstall the previous version (6.0) of the program?
There are a couple ways to do do this.
Assuming you want a major upgrade ( deploy everything again), you just need to go to the upgrades and right click, add major upgrade.
Once you have the major upgrade, you can choose any previous version.
I have an Installer project for my application in Visual studio 2010. I was successfully able to make it uninstall the older version of the application before installing the new one by
1. Setting RemovePreviousVersion to false
2. Setting DetectNewInstaller to true
3. Incrementing the project version
4. Creating new product code
Now when I double click my application for installation, I want the the setup wizard to also show that the currently installed application is getting uninstalled before showing the progress bar for fresh installation. How can I do this?
That might be a typo, but you need RemovePreviousVersions=True for the previous version to be uninstalled, as the actual name implies!
Otherwise, this is just the way VS (and most other tools) behave because Windows Installer's upgrades are like that, embedded in the new install. That progress bar behavior includes the uninstall of the old product, not just the fresh install, and the uninstall occurs after the new product has been installed. It's all one transaction.
With another tool you could build your own dialog that says there's an upgrade going on based on the detection of the older product, but generally speaking that's quite rare. Customers typically know what they have installed, and they are well aware that they are about to install an upgrade, that seems to be the assumption behind the default behavior.
We have an installer package authored with InstallShield 2009, targeting Windows Installer 3.1.
Recently, we started to notice that sometime, when installing on some Windows 2003 R2 x86 based hosts, the installation fails, and the installer log report a 1603 error code (which by the way, doesn't really help much, as it means ERROR_INSTALL_FAILURE, that is a very generic "A fatal error occurred during installation.").
As the installation is still working on some other hosts on that very same platform, after further investigation we found out it was happening on hosts where Sql Server 2008 R2 was already installed, which leaded us to find out the issue is really with Windows Installer 4.5.
Whenever Windows Installer 4.5 was installed by an installer package, our installer package is failing with 1603. So far, we found as a work around: if we manually uninstall Windows Installer 4.5 (running something like "C:\WINDOWS\$NtUninstallKB942288-v4$\spuninst\spuninst.exe"), we can then run our installer package successfully, but this has various drawbacks:
the user who uninstall Windows Installer 4.5 is prompted with a dialog listing all the various software products installed using that, and effectively the link between those products and Windows Installer 4.5 is lost after uninstalling that, even if we reinstall it after successfully installing our application;
as Microsoft released various version of Windows Installer 4.5, the location of the utility to uninstall that is not strictly the one given above;
It is awkward to ask customers to perform such a work around.
I suppose upgrading the installer package to target Windows Installer 5 may solve the issue, but if possibile I would like to avoid it, and continuing to use InstallShield 2009 to author this specific package.
I have scoured the Microsoft and Flexera Knowledge Bases (and I am continuing my investigation), with no avail so far.
Does anyone knows if Microsoft or Flexera, or any other third party, have published an hotfix, or some further info, about this issue?
Some info about the 1603 error code failure
We got verbose logs for this issue, from at least 3 different servers, and we have investigated that in depth, to not avail so far. Most actions return 1, some 0 (specifically IsolateComponents, MigrateFeatureStates, IsolateComponents, SetODBCFolders, MigrateFeatureStates, UnpublishComponents, UnregisterComPlus, UnregisterTypeLibraries, UnregisterMIMEInfo, RemoveShortcuts, RemoveFiles, CreateShortcuts, RegisterMIMEInfo, InstallODBC, RegisterTypeLibraries, RegisterComPlus and PublishComponents, but nothing has yet came out investigating those), the installer package seems actually to be almost able to install (perform all the sequence down to "INSTALL. Return value 1.", it even prints "Product: [Our Product] -- Installation operation completed successfully."), only then it starts to rollback everything, and as there are various errors on the rollback, I think some of those will cause the 1603 (probably some 1607 returned by MsiProvideAssembly on ISChainPackagesCleanup), but the point is that it shouldn't rollback, and with Windows Installer 3.1 (or 5.x for that matter) it doesn't, it does rollback only when there is Windows Installer 4.5 installed on a Windows 2003 x86 environment.
Most likely your package has an action which fails, either custom or standard. Try creating a verbose log of the installation which fails (it's very important to be verbose). After the failure, open the log with a text editor and search for the error code (1603) to see what triggers it.
As a side note, don't try to blame Windows Installer. There's nothing wrong with version 4.5 and there are no hotfixes or something like that. The problem is in your package. It does something which is either incorrect or unsupported.
EDIT:
From your post update it looks like a failed chained installation. No errors are shown in the log because the error occurs in a different installer process.
If you are not using chained packages, try looking for errors in the Event Viewer.
If you are using chained packages, you can try enabling the Windows Installer logging policy and check for logs generated by them. Most likely one of the packages is encountering a problem.
Are there any hacks around the normal (and infuriating) Visual Studio Deploy Solution numbering system?
I have many assemblies I'm deploying with a Major.Minor.Build.Revision scheme for assembly versions. When I set the version for the setup.exe/Installer.exe, I can only do Major.Minor.Build. I'm not allow that fourth section for revision. This causes an issue because I key build numbers off date. So if my build is 906 for 09/06/11, I can only install (not uninstall and install, just install) once a day as it will see a previous version with the same version number and say a previous version is blocking install.
Besides using InstallShield (can't use this due to client requirements), are there any hacks to get the normal deploy solution to accept four part versions?
Windows Installer ignores the fourth Product Version field. So as long as you are using MSI packages, there's not much you can do. The old build needs to be manually uninstalled before installing a new build.