I'm trying to create an installer for a C# application but I'm having this weird issue with the installer that apparently others have encountered before. So basically if I build the setup project once and use the generated installer to install the application on a machine, then come back and double click that same installer on that same machine, I get the dialog that allows me to either "remove" or "repair" the current installation, which is what I want.
However, if I rebuild the setup project without making any changes to code or the setup project options and run that newly generated installer on that same machine, I no longer get the "remove" or "repair" options, it just errors out:
Code Block
Another version of this product is already installed. Installation of this version cannot continue. To configure or remove the existing version of this product, use Add/Remove Programs on the Control Panel.
See the setup log file located at 'C:\DOCUME~1\MyUserName\LOCALS~1\Temp\VSD1262.tmp\install.log' for more information.
In the log file, the error is as follows:
Code Block
MsiInstallProduct returned '1638'
Error: Another version of this product is already installed. Installation of this version cannot continue. To configure or remove the existing version of this product, use Add/Remove Programs on the Control Panel.
I even have the "RemovePreviousVersions" flag in the setup project properties set to true. So what gives? Is this an issue with the windows installer?
Shouldn't I be able to build the installer as many times as I want and get the same behavior if no code and/or configuration changes took place? The only thing that works is incrementing the version number and allowing it to generate a new product key, but I doesn't make sense to have to do thatjust to rebuild the installer. If the product key and version key are the same, it should work the same shouldn't it?
Any help/suggestions are greatly appreciated. Hopefully there's a workaround. Thanks.
|
| Miguel Sevilla Friday, November 09, 2007 4:48 PM |
Miguel,
what you are seeing is exactly the expected and intended behaviour. Whenever you change anything in your setup, a new PackageCode needs to be assigned, which will cause this "another version is installed" message. Therefore Visual Studio automatically changes the PackageCode for you on each build.
Well, if you don't make ANY changes, this wouldn't be required. But what's the point of rebuilding then?
Quote from http://msdn2.microsoft.com/en-us/library/aa370568.aspx:
No two nonidentical .msi files should ever have the same package code. It is important to change the package code because it is the primary identifier used by the installer to search for and validate the correct package for a given installation. If a package is changed without changing the package code, the installer may not use the newer package if both are still accessible to the installer.
|
| Stefan Krueger Tuesday, November 13, 2007 9:13 AM |
What exactly are you running? It looks to me that you're running the setup.exe again, and the that's what's reporting the error 1638. It would do that if its detection mechanism was broken and it wasn't detecting that a prerequisite product is in fact already installed. |
| PhilWilson Saturday, November 10, 2007 12:03 AM |
Hi Phil, thanks for your response. Let me try to clear things up. Basically, while testing the setup project for an application, I ran into the 1638 error. Here is what I did:
1) Build setup project in visual studio via the "Build" option (it generates an installer: setup.exe)
a) Run setup.exe on MachineA and install the application (the installation is successful)
b) After the installation completes, Run setup.exe again (the "remove" or "repair" installation dialog pops up which is the desired behavior)
2) Rebuild the setup project in visual studio via the "Rebuild" option (it removes the previous setup.exe in the release directory, rebuilds the setup project again, and it regenerates the setup.exe)
a) If I take the newly generated setup.exe and run it on MachineA again, I don't get the "remove or repair" dialog that I got in step 1b above, I get the 1638 installer error.
It seems as though when I rebuild the installer, the detection mechanism is breaking, because instead of showing me the repair/remove dialog, I get an error dialog. Am I not supposed to rebuild the setup project as many times as I want and expect the same behavior from the installer as long as the product code and version number haven't changed?
|
| Miguel Sevilla Saturday, November 10, 2007 5:40 AM |
Miguel,
what you are seeing is exactly the expected and intended behaviour. Whenever you change anything in your setup, a new PackageCode needs to be assigned, which will cause this "another version is installed" message. Therefore Visual Studio automatically changes the PackageCode for you on each build.
Well, if you don't make ANY changes, this wouldn't be required. But what's the point of rebuilding then?
Quote from http://msdn2.microsoft.com/en-us/library/aa370568.aspx:
No two nonidentical .msi files should ever have the same package code. It is important to change the package code because it is the primary identifier used by the installer to search for and validate the correct package for a given installation. If a package is changed without changing the package code, the installer may not use the newer package if both are still accessible to the installer.
|
| Stefan Krueger Tuesday, November 13, 2007 9:13 AM |
Hi Stefan, thanks for your answer.
| Stefan Krueger wrote: |
|
...Therefore Visual Studio automatically changes the PackageCode for you on each build.
Well, if you don't make ANY changes, this wouldn't be required. But what's the point of rebuilding then?
| |
I wanted to be able to rebuild the installer for a specific version of an application as many times as necessary without having to generate it once and then have to archive it somewhere (or even add it to source control).
|
Quote from http://msdn2.microsoft.com/en-us/library/aa370568.aspx:
No two nonidentical .msi files should ever have the same package code. It is important to change the package code because it is the primary identifier used by the installer to search for and validate the correct package for a given installation. If a package is changed without changing the package code, the installer may not use the newer package if both are still accessible to the installer.
| |
That was exactly what was happenning. So basically, even though the version number, product code and upgrade codes were kept intact,visual studioregenerates a new package code (aka Revision number) on every rebuild of the setup project.
Thanks again. |
| Miguel Sevilla Tuesday, November 13, 2007 10:06 PM |
In general, it's desirable to change the PackageCode with each build. It was a common mistake not to do so, until setup authoring tools started to change it automatically for you on each build.
Some tools have an option where you can select not to auto-generate the PackageCode, but Visual Studio doesn't give you this flexibility.
|
| Stefan Krueger Friday, November 16, 2007 7:40 PM |
Sorry Stefan,
The behavior is neither expected nor intended.
The issue revolves around the source location of the MSI file.
We've experienced building to identical installations (Batch build) of 1) Single installation (CD) and 2) Web-based download.
The single installation via CD works as "we" would expect by prompting for repair or removal. The web-base installation fails clumsily like a drunkin sailor. Heck if the resource is missing you can't even specify the resource's location unless it is file protocol based (no http here).
Lack of QA resources at the MFG is the ultimate issue.
|
| Rich C OBrien Tuesday, June 10, 2008 8:35 PM |
Rich, did you guys find a workaround for this problem?
|
| Miguel Sevilla Thursday, June 12, 2008 3:10 PM |
The error message (Another version of this product is already installed....) is expected if you launch an msi file for an already installed product (as identified by the ProductCode) with a different PackagCode as used for the original install.
If the two msi files are exact copies of each other then you wouldn't have to change the PackageCode. However I wouldn't recommend rebuilding the msi file for this purpose, as I wouldn't trust that the result is an identical copy of the previous build. Instead I would extract the msi file from the web build for use on the CD.
However if you are sure that your two builds generate identical msi files you may keep the PackageCode unchanged. If Visual Studio doesn't have an option for this purpose, you could either edit the PackageCode post-build, or use a more powerful msi authoring tool. |
| Stefan Krueger Wednesday, June 18, 2008 8:23 AM |
Hi Guys,
I found the same problem and I have to go to Control Panel each time to remove the installed program.
Is there any solution that when the Setup Project is built, it looks if any current version is available then shows the "Repair or Remove" option, or an "Upgrade" option?
Many thanks |
| Dynamic Tuesday, July 01, 2008 4:07 PM |
If you set "Detect existing version"and "Remove previous version" to yes, and increment the product version number, then the old version should be removed automatically. This is called a "Major Upgrade".
|
| Stefan Krueger Thursday, July 10, 2008 1:13 PM |
Hello,
To: Stefan Krueger
I Still have the problem that the setup exits with code 1628 on the client machine.
The 3 requirements are correct:
"Detect existing version" = yes
"Remove previous version" = yes
"Automatically increment version with each publish" is checked
anyone an awnser to this problem?
thx a lot
|
| LudwigGhislain Monday, July 27, 2009 1:00 PM |
index > ClickOnce and Setup & Deployment Projects > Setup Project Problem (MsiInstallProduct returned '1638')