I'm faced with little "inconvenience" using Visual Studio 2010 setup and deployment projects. Let's say I have 2 applications: App1 and App2. Both applications have separate MSi installation packages and can be installed to different locations. App1 need to know where App2 is installed. Previously I was provide App1 with "ProductCode" value of installation package of App2. This way App1 could find installation path of App2 looking for appropriate value in "ProductCode" key in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall.
Now I was updated the version of App2 installation package and Visual Studio urged me to change the ProductCode. It was changed and now App1 can't successfully use previous ProductCode to find installation path of App2. Of corse I can give new ProductCode to the App1 but I will be forced to do this each time when App2 version updated. Also old version of App1 will be unable to find new version of App2 because new ProductCode will be unknown for it.
So I need more "persistent" method to find App2 installation path. I think of UpgradeCode value of Visual Studio setup and deployment project which is never changes unless developer will change it himself for some reason. But I couldn't find any trails of UpgradeCode in the registry.
Is anyone know where UpgradeCodes are saved? Or probably the way to find actual ProductCode when we know UpgradeCode exist? Maybe someone have a better method of finding installation paths of applications?
Thanks in advance.
Use the MsiEnumRelatedProducts function to enumerate products that match the upgrade code.
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.
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 have a Setup Project that I made using Visual Studio 2010.
The application that I made (and which the Setup Project deploys) has been released for a while now such that there are users that have the application already installed on their machines.
Since the initial release of the application, the company that I work for has changed its name. Without thinking too much about it, I simply changed the [Manufacturer] name in the setup project's Deployment Project Properties to the new company name.
Unfortunately, now when a user updates their existing installation of the application with the new updated application, the directory that was in \Program Files\Old Company Name remains untouched and a new directory \Program Files\New Company Name is created and the new update is installed in this new directory.
It makes sense to me why the scenario above is happening - However, do you know if Visual Studio has options/settings that I can set that will tell the setup project to rename the existing \Program Files\Old Company Name directory to \Program Files\New Company Name and then install the update in that new directory?
If this is an update to the application then, it is really only possible through custom actions as Mark Hall suggests. However if it is a complete installation of the application then it is possible to force a uninstall of the previous version and the reinstall to the new version to the new folder.
In your Setup Projects properties update your Major version number and allow the "Product code" guid to be updated, ensure that the "RemovePreviousVersion" is true and that the "UpgradeCode" has not changed.
This should force the uninstall of the previous version and install the new version to the new folder.
To answer your question. No there is no built in way to rename your directory before install through the Visual Studio Setup Project. If it could be done it would need to be through a Custom Action See this MSDN Forum link on Custom Actions and this Forum Link also. Your best bet might be to to a full installation and then copy any settings from the old directory to the new directory then delete the old directory. That can be done running a Custom Action during the commit actions of the setup.
If you don't need the \Program Files\Old Company Name directory anymore, can't you remove it as part of new installation?
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 Windows Forms application with an installer (.msi) already created with Visual Studio. I am now creating a new installer for version 2.0 with the property RemovePreviousVersions set to true.
Now, when I install 2.0 over 1.0 it removes 1.0 and installs 2.0 completely.
Is there a way that I can tell the installer if you find some files already installed (like .xml files used for data) then don't override them?
I am trying to have my 2.0 installer serve the 2 purposes:
Install from scratch for new users
Existing users will upgrade but not lose their customizations
The deployment project in VS does not overwrite files. What happens is that since you have RemovePreviousVersions set to true, when you change your program file version and the ProductCode GUID of the setup project, it will first uninstall the previous version and then will do a clean install of the new version.
To make sure some files don't get overwritten, I usually exclude them from the Content or Primary output files (wherever they are located) and then add them separately to the setup project. Doing this, you can individually set properties for those files. The property you are looking for is called Permanent" that if set to true will never uninstall the file in question, and therefore will never overwrite it with a new version. The only drawback with this is that when you uninstall the product, the Permanent files will not get removed from their target locations, but in my case (usually local DB files), that's a good thing ;)
Cheers!
[edit] The above is true for VS 2008 SP1. Haven't tried it on other versions, so hopefully you are using the same VS version or it works for the version you use.
[edit2] Oh, also you could also use the "Condition" property to achieve something similar. If you do that, make sure that "Transitive" is set to True so the Condition is always evaluated. Haven't tried it with Conditions, but that's another option you could look at. Other than these 2, I think that's pretty much it for VS deployment projects.
When I was in a similar situation what I did was:
The files that were customized by each user and should NOT be touched by the installer were NOT included in the MSI (NOT in the Visual Studio Setup Project). When the app was run for the first time I generated the XML files through the code.
The files that were static (e.g. data that was used to populate Dropdownlists) I included in the MSI and I can update those by building a new MSI with Visual Studio.
Basically don't include customizable files in your MSI project. Create them in code for new users.
I never looked into telling the MSI not to update certain files that are included in the MSI file. The solution I came up with was perfect for me. I don't know if it can be done.
I hope this helps.