Software Deployment

MSI can't control this automatically. You need to have a custom actions to prevent installing older version on top of newer version.
Custom Action type 19 displays an error message, returns a failure and terminates the installation.
Use ActionProperty to identify a newer version installed and then use this property to execute custom Action type 19 to terminate installation.

[font="trebuchet ms"]Yes right.

But my concern is that, since the old version of the appl. is already been released. We are releasing the new version now. So, if i add this CA type 16 in the new version, and if i install the old version, how this will be affected?

Thanks.

This will be affected from future releases.
As the older version is already released, and it can't identify whether a new version is already installed. Hence, there is no link between these versions and installer won't be able to prevent this older version to be installed on top of the newer version.

[font="courier new"][font="trebuchet ms"]Ok. Then seems that my prob couldn't be solved.

Thanks for the assistance.

Have you checked the UPGRADECODE matches? I wonder if it's different rendering the installation a different product in the eyes of Windows installer.
This is from the Windows Installer book. BTW I'm a complete beginner and humbly hope this helps. There's a lot of material on the aforementioned field if so.

"A major upgrade takes the position that the simplest way to update an installed product is to completely uninstall the old version and then install the new version. Windows Installer supplies an automatic mechanism to make this seamless; installing the new version also removes the older one. In Chapter 2 you looked at the GUIDs that are used to define a product and its packaging. In particular, the UpgradeCode GUID is intended to be common across all versions of an upgradeable product, even though the Product code can change. The UpgradeCode is the key to a major upgrade.
A major upgrade requires three key changes to the installation package:


The ProductCode GUID must change.

The PackageCode GUID must change.

The ProductVersion must be changed (and this means incremented).
The UpgradeCode GUID stays the same as previously mentioned.
Internally, in the MSI package, the Upgrade table (together with some standard actions) makes the major upgrade remove the prior version of the product as it installs the new version"

Have you considered using a minor upgrade for the new release? That would prevent the 2 applications from installing side by side and would give you time to update the install to properly support major upgrades.

I tend to put entries in the upgrade table to check for older and newer versions of the app. Then provided you do not change the upgrade code all releases will be able to test for newer and older releases. A custom action type 19 can then be used to display a message if a newer version is detected and cancel the install.

[font="trebuchet ms"]Hi Guys,

Thanks for your suggestions.

I have taken care of all those. Major Upgrade is happening fine, as expected. But, my problem is vise versa(pls read my first post in this thread). After installing the latest version, the older version is also getting installed parallelly.

Hope i m clear.

Thanks.

ORIGINAL: getIT
[font="trebuchet ms"]After installing the latest version, the older version is also getting installed parallelly. Do the version use different target folders and registry keys, then? If so, what's the problem, other than cerebrally-challenged users?

Since you imply that you "own" the application, why not add a test for other versions into the EXE itself and, if present, kcik off an uninstall of any but the latest version? You can prompt the user that this will happen, if you think you need to.

[font="trebuchet ms"]Do the version use different target folders and registry keys, then? If so, what's the problem, other than cerebrally-challenged users?

No, both the versions have the same target folders and more or less the same reg keys.

The old version got released, so no use in modifying that.

Clearly then, your files are not versioned, not time-stamped properly or are set to force-install (i.e. to ignore versioning, time-stamp).

As for handling this in the EXE, I was referring to the new version having functionality added to uninstall older versions.

[font="trebuchet ms"]Ian,

The files are versioned, and also time-stamped. As said earlier, the new version is behaving perfectly as expected (uninstalling older verions, if installed, and then install the current one).

IMHO, since this is a major upgrade, I belive this is the expected behaviour. i.e., older versions can uninstall over the new versions. Refered here in one of the acresso links.

Thanks.
[font="trebuchet ms"]

ORIGINAL: getIT
[font="trebuchet ms"]IMHO, since this is a major upgrade, I belive this is the expected behaviour. i.e., older versions can uninstall over the new versions. Refered here in one of the acresso links. No link, but anyway...

Well yes, for the newer over the top of the older, but your query was for the reverse, wasn't it? My experience in that scenario is that you'll be prompted that a newer version is already installed, upgrade or not. Or maybe my grey cells are decaying faster than I thought! :)

[font="trebuchet ms"]Yes, my query was [font="trebuchet ms"]'for the older over the top of the newer'. I want this not to be done.
No prompt that newer version is already is installed. That is my problem.
But, i read that this is the behaviour of Major Upgrades.