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.
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 brought up a new VS2017 dev environment at work yesterday, which means I got the recently released version 15.3. I'm getting an internal compiler error on a VC++ project that nobody else in the organization is getting; everyone else is still on 15.2. To test my theory that the 15.3 update may have broken something, I want to install VS2017 15.2 (or even 15.1 or 15.0). But I can't figure out how to do that. When I run the 15.0 or 15.1 bootstrapper, it still tries to install 15.3.
I've already gone over this guide for creating offline installations but it doesn't say anything about getting an older release. I found a guide here that shows how to use a specific release with VS2015, but I can't find anything for VS2017.
My work gave me an MSDN account (Visual Studio Professional), which offers older bootstrapper downloads, but does not offer full offline installation downloads for older releases.
How do I install VS2017 15.2 (or 15.1, or 15.0) when 15.3 has already been deployed by Microsoft?
There is support for downloading a prior version, but evidently you have to contact support for the link. None of the links on any of the pages I could find within the VisualStudio.com site referenced it.
Installing an earlier release of Visual Studio 2017
Be sure to take the time to read the "[no]support policy" regarding "earlier" releases. Essentially, the day they released version 15.4, version 15.3.5 was no longer supported.
On another note, I have noticed many people seem to respond (here and on other similar postings) along the lines of "Why on earth would you want to reinstall the same version you were working with instead of the latest release?". Note that I am para-phrasing that to clarify the sentiments commonly expressed.
The reason is because TEAMS of developers need to be on the SAME version of the tool set. They have deadlines and cannot afford to drop everything and switch everybody to a new version of the tools that may or may not work correctly for them. Even if the developers were willing to take that hit to their productivity, usually their managers are not. This is why taking away the option to install the previous version the very same day you make a new release available is an unacceptable practice for Enterprise or Professional grade development software.
Another common reason is that when bugs have to be fixed in software, you often need to use the same, or very close to same, version of the tools to rebuild it after fixing the bug. The costs of regression testing after forcing a non-trivial upgrade on an entire software product or suite is unacceptable to most organizations. Upgrading may not even be an option due to contractual obligations.
It seems that based on this article that Microsoft do not offer a mechanism to download any version of Visual Studio 2017.
The https://my.visualstudio.com site offers bootstrap downloaders for 15.0 and 15.3 only. Intermediate versions such as 15.1 and 15.2 are not available as of September 2017.
I have a modest sized engineering team that would quite like to stay with 15.2 even for new starts and this is quite frustrating as we didn't capture an offline install of anything other than 15.0!
Apparently its possible to install a older version in parallel to a newer one. I just downloaded 15.6.7 from https://learn.microsoft.com/en-us/visualstudio/productinfo/installing-an-earlier-release-of-vs2017 and started the install - it didnt touch my existing installation 15.9.19
But the probably better solution is just to install the toolset which is available separately for each VC2017 release. See this intersting article:
https://devblogs.microsoft.com/cppblog/side-by-side-minor-version-msvc-toolsets-in-visual-studio-2017/
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 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.
I have a registry key (in HKEY_LOCAL_MACHINE hive) which must be keeped from older version of the application to the newer, but removed when user completely uninstalls my application. I'm using Visual Studio 2010 setup and deployment project.
I know about increasing build version of the installation package, build version of assemblies and upgrading 'ProductCode'(but keeping 'UpgradeCode' the same). 'RemovePreviousVersion' is set to true. The problem is that when user installs the new version, registry key from previous version is removed (with important data in it) and recreated again. It seems that MSI uninstalls my application before installing the new version. I was tried to set 'RemovePreviousVersion' to false but in this case new version installed independently and both versions of the application appear on the same machine.
It seems to be very common scenario but I couldn't find how to keep registry keys between different versions. If you know how to make this modifying MSI package using Orca it is not a problem (as Visual Studio is very restricted in creating installation packages).
Thanks in advance.
A late scheduling of RemoveExistingProducts action will fix your problem.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa371197(v=vs.85).aspx