I'm using vs 2010, and i generate a setup file, i do have RemovePreviousVersion true and DetectNewerInstalledVersion true, at the start i had problem to remove previous version but with a hack in the MSI file it is working, not if I try to install a setup file where I have a higher one already installed on my machine, it won't be detected and will be installed separately. I'm not sure why it is not working, is it because the older version setup file was created by VS2008 ?? and didnt have the option of detectingNewerinstalledVersion true.
who will check for the newer version the older setup version or the newer version will prevent it.
thank you for you help in advance
Jp
In order for two setup projects to be considered the same application they should have different product codes, identical upgrade codes, and different version numbers.
It's hard to tell from your question if this affects you, but there is a serious issue in the way Visual Studio 2010 setup projects handle "upgrade" installations. If an assembly in the older setup has the same AssemblyFileVersionAttribute as the one in the newer setup, the installer assumes the file has not changed and will not replace it with the newer file.
One possible workaround for this problem is to include the [ProductVersion] in your installation directory.
Related
I just installed VS2013. As there is no longer the Setup Project, I installed InstallShield LE. I used integrated import wizard and hoped any newer build would automatically update older versions created with VS Setup project. Well, I used to alter the Product Version, which prompted me to alter the Product Code, and that was it. Now I thought this should work with InstallShield as well, so I updated the product version and manually generated the product code. I had the older application installed and tried to reinstall it with this new IS LE setup. And the result is: There are two applications installed, which have exactly the same name and path (it installed in the same directory), but different version. I can really see 2 programs with the same name in "Programs and Features". I checked the upgrade code, it is the same for both. What did I do wrong?
Thanks
Check the installation type, i.e. per user or per machine. It must be the same for both versions, otherwise Windows Installer will skip removing the old versions and you will end up with both versions on your machine.
A verbose log created when you install the new version should also be helpful, you can search for FindRelatedProducts and RemoveExistingProducts standard actions in it, to see why the old version is not removed.
Well finally we were able to solve the problem. You need to place an entry to the Upgrades Path section. Oddly enough You need to do this manually and it's not done automatically by the IS import wizard.
Strange issue, but it is bothering me.
When I tried to deploy msi package is not completely updating the previous version. but the version is been updated in control panel but not UI (changes made in UI is not reflecting).
DetectPreviousVersion = True;
RemovePreviousVersion =True;
Installallausers=true;
The product version is higher number than previously installed version, and changed the product code for each higher version.
upgrade code of the previous installed version and new version are same.
If I remove the previous version manually and then install the latest version then I could see the changes in UI.
Proper versioning of your DLL's and EXE's would prevent this.
File Versioning Rules
At the core of any installer is the actual installation of files.
Determining whether to install a file is a complex process. At the
highest level, this determination depends on whether the component to
which a file belongs is marked for installation. Once determined that
a file should be copied, the process is complicated if another file
with the same name exists in the target folder. In such situations,
making the determination requires a set of rules involving the
following properties:
•Version
•Date
•Language
possibly duplicate question:
but for viewers the answer is adding an extra property to msi package using orca.
REINSTALLMODE=amus
amus-updates the all files on upgrade
omus- updates files that are only changes as installer identifies
refer to original answer here
Older versions of Visual Studio setups used to effectively uninstall all the old files and then install the product and it's files. VS 2008 and later require you to update the file version of files that you want to overwrite in the upgrade.
I am using a setup project in VS 2010 to install a windows form application I have created. The setup project works great, however, if I update the application and change the version number and upgrade code of the setup project it does not update the application on the user's machine when the setup project is run again. It will go through the install steps and say that the installation was successful, however, the application that is on the user's computer remains exactly the same and is not the newer version. Oddly enough, if you were to run the setup project again an error will come up saying that this version of the application is already installed and that you must use the add/remove programs to remove the current version to continue with the installation. Has anyone else experienced this issue before. I have heard that this may not be possible using the setup project in VS 2010, but I am hoping that is not the case as this method has worked great for me with the exception of this issue.
You should not be changing the UpgradeCode property, this will have exactly the effect that you are seeing:
Caution
The UpgradeCode should only be set for the first version; it should never be changed for subsequent versions of the application, nor should it be changed for different language versions. Changing this property will keep the DetectNewerInstalledVersion and RemovePreviousVersions properties from working properly.
( via https://wayback.archive.org/web/20121029130031/https://msdn.microsoft.com/en-us/library/465253cd(v=vs.100).aspx )
Assuming you want to remove the old version and replace it with the new one (as opposed to having them installed side-by-side, which is actually what you're doing) you should change the Version (of both the MSI and the file(s) being updated) and the ProductCode (of the MSI) and set RemovePreviousVersions to True.
I encountered same problem.
and I resolved with changing those four.
(I used Visual Studio Community 2019)
[setup project]
・Version
[.Net project]
・Assembly Version
・Assembly File Version
・GUID
I'm setting up an automatic deployment scheme. It would be really handy for us if we could put older msis on the server and have all the clients roll back to previous versions if one of our new releases turns out to be too bug riddled.
Right now, the msi is bitching at me "Unable to install because a newer version of this product is already installed". What kind of property can I set to turn this behavior off? I will gladly do so in my post build vb script.
Thanks
Isaac
Are you using a group policy on your
domain to deploy the msi?
Do you have
a setup project for your msi in
Visual Studio?
Anyhow, I see a solution but not sure if that's right for you...
You need the code matching the old msi that you want to deploy back.
Open the solution matching the code of the old msi.
Using <F4>, open the properties window of the setup project matching the msi,
Increment the Version to a higher number then the one currently deployed. It will ask if you want to change the product code, click Yes.
Rebuild the setup project then deploy.
Since the built msi has a higher version number, it will update the one deployed.
I solved this by changing the DetectNewerInstalledVersion property to false.
It doesn't bitch anymore about this.
Now, with the script that sets the REINSTALLMODE to amus and this setting, my msi will overwrite anything regardless of version.
I have a web setup project built using VS2008. I've converted my solution to VS2010 and now when I build my new installer and run the install from the MSI it installs fine, then at the last step, removes all the files it's just installed.
I have RemovePreviousVersions set to true. If I turn this off the files remain in place (but I get multiple instances in the Programs and Features in the control panel).
If I run the install again, the files reappear. From then on, the files always remain, even when installing another version. So, the problem seems to be with running an installer built using VS2008 and then running the same installer built by VS2010. The upgrade GUIDs on each installer are the same.
What is the cause and how can I fix this?
I haven't tried porting a setup from VS2008 to 2010, but having the same upgrade code for different build versions will cause problems; simple explanation is the msiexec installer fails when it tries to remove the old components because the older components have the same upgrade version as the newer components being installed. There is a VS project setting where you can automatically generate a new upgrade code each time you rebuild your .msi; I generally select this and saves a lot of these versioning headaches.
Uninstall all copies of your app using
add/remove programs
Delete the contents of your %TEMP% folder ( to
get rid of any "old" (VS2008) copies
of your .msi)
Update the GUID for the VS2010 version (I think you do this by right clicking on the
GUID in the properties window and clicking "genereate new GUID")
rebuild the project and try again!
I just encountered this error. Had the exact problem when upgrading. I tried the solution at:
https://connect.microsoft.com/VisualStudio/feedback/details/559575
I edited my MSI-file in Orca resequenced RemoveExistingProducts right after InstallInitialize (sequence number 1501). This was found in the InstallExecuteSequence table. This was originally sequence number 6550.
That solved my problem.
What I've discovered is that changing the UpgradeCode will prevent the files from being removed, however it's then treated as a separate installed program - i.e. in the control panel (Programs and Features) my program appears twice. Logically, I think, this is because it's not the same program.
My only option seems to be to programmatically uninstall the old version in the installer of the new version by writing a custom action.
I've submitted a bug to Microsoft Connect and they've confirmed it's reproducible.