1
votes

I'm investigating some issues our group is having with our installations. I haven't been involved with our installations much in the past so I'm not very familiar with it. I want to make sure we are following good practices.

What I'm confused with is determining when to change the Version property.

MSDN has a really good guide on when to update ProductCode, Version, etc... http://msdn.microsoft.com/en-us/library/windows/desktop/aa370579(v=VS.85).aspx

However, I'm unsure how to apply that to the way my group has been doing it in the past. The current process is to never change the version number. It's at 1.0.0 and has been for a long time even though it has had many updates (including VB6-->VB.NET conversions).

My group only really maintains two versions of our product at any one time, the current Production and a Beta. We don't send out updates or hotfixes, just completely new releases. So this is the only differentiation we need between those two versions. However, a User can only ever have one version installed at the same time. Apparently, keeping the version number at 1.0.0 helps with installations. This doesn't seem like a good way to do it.

I'd at least want the MSI to have a new version number. Does anyone have recommendations given my group's current process? I'd want to make sure that whever a user goes to install a version, it updates whatever version of that application is already on that machine.

Thanks in advance guys!

1
Your post is not very clear. What exactly are you asking? - rmrrm
Hi Cosmin, I'm trying to determine when to change the version number on my setup project. I've read the MSDN help on it but I'm still not very clear on it. I know my team needs to start updating the version # on those builds, but I'm not sure when to do that and when to change the product code. I don't fully understand what the product code does and why it needs to change if it's the same product, you're just updating it (so it gets a new version number). - StoneJedi

1 Answers

2
votes

You can make your packages automatically uninstall older versions by using the major upgrade mechanism. Basically, each time you want to release a new version of your application, you increase your setup project Product Version and change the Product Code.

You also need to make sure that RemovePreviousVersions property is set to True.

The rule of thumb is to create a new version of your package each time you modify one of your application files and want to distribute that modification.

An alternative to major upgrades are patches. They contain only the updated files and do not require a new Product Code. However, you need a different setup authoring tool to create them. Visual Studio cannot create patches.