Bug in IS2010 - installing older version

[applemac]

I don't know if anyone here ever tried to build an older version of the package with IS 2010 and install the package on a computer that has higher version of it.

It gives the following error message and aborts mercilessly:

"The setup has detected that version x.x.x of product is already installed. This setup installs an earlier version of product(x.x). You will have to uninstall the previous version before installing the version."

If anyone knows the fix, please help.

Thanks

[MichaelU]

Hmm. Do you have validation enabled under Tools > Options? If so, disabling it might work around this... That said, it's probably better to build on a clean environment. 😮

[edit]
Whoops, I totally misread. I thought you said you encountered this error while building. Lurean's response below is correct. That said, if you are intent on changing this, there is a custom action of type 'error' which you can remove or change the condition.

[Lurean]

that is the expected behavior when an installer encounters a NEWER version in place. If you want to downgrade to an older version you have to manually uninstall the newer version first.

This is intended to prevent you from downgrading an application on accident. So if the one you are installing is version 1.1 and version 1.1.1 is installed already you should see that message you posted.

[applemac]

Do you mean "this is expected" for packages built with any version of IS? Or this is expected only for IS2010? Will upgrading ism file from IS2008 to IS2010cause this?

We've have been using many versions of InstallShield for long time. Until IS2008, there was no error with our packages, even when we downgrade to a lower version.

This is totally a new bug.

[Cary_R]

Hi Applemac,

This is indeed new behavior starting with InstallShield 2008, but it is not a bug. Basically, we included the custom action and Major Upgrade item 'ISPreventDowngrade' based off of Vista best practices we got from Microsoft.

Projects migrated from pre-2008 won't have these enabled. Only new projects in 2008 and later will have it set up like this. So perhaps most of your products up to this point were migrated, and so don't have this behavior?

Some docs that talk about this are:

http://kb.flexerasoftware.com/doc/Helpnet/installshield14helplib/PreventingDowngrades.htm

http://msdn.microsoft.com/en-us/library/aa370840%28VS.85%29.aspx

We also throw an error now if you don't have an anti-downgrade custom action in your package, and you're validating with the ISBP validators:

http://kb.flexerasoftware.com/doc/Helpnet/installshield14helplib/ISICE19.htm

But, as Michael said, if you don't want this behavior, you can just remove ISPreventdowngrade from the Upgrades view, and the Custom Actions view.

[applemac]

Hi,

Yes, most of our products are migrated. I cannot find Custom Action or Upgrade View.

We are using Installscript.

Thanks

[Cary_R]

Hi,

I suspect that the same enhancement went into InstallScript projects during OnUpdateUIBefore--in this case, try overriding this event, and modifying the code that's here. At the very least, you'll get some code that has a similar purpose like:

// Check whether the update is older than the currently installed version.
if( nResult = VERSION_COMPARE_RESULT_OLDER ) then
szMsg = SdLoadString( IDS_IFX_ERROR_UPDATE_NOT_APPROPRIATE );
SdSubstituteProductInfo( szMsg );
MessageBox( szMsg, SEVERE );
abort;
endif;

// Verify that this update is appropriate for the version of the application that is installed.
if( nResult = VERSION_COMPARE_RESULT_NEWER_NOT_SUPPORTED ) then
szMsg = SdLoadString( IDS_IFX_ERROR_UPDATE_NOT_SUPPORTED );
SdSubstituteProductInfo( szMsg );
MessageBox( szMsg, SEVERE );
abort;
endif;

[applemac]

Thanks Cary. That worked 🙂

But its quite annoying to find such a major bug by myself and have a code fix for that and IS has no idea about this bug since the release of IS2008?

[MichaelU]

We consider this a feature, as it is unlikely someone truly wants to replace a newer version with an older version. It's a bad scenario in several ways, as the older version of the install cannot have been tested as a downgrade before it's released, and things may have been irrevocably altered by the newer version so the downgraded software may fail.

As Cary showed, there is still the necessary flexibility to get the behavior you request; the default has merely been changed for the (general) better.

[applemac]

Reply from my manager:

I thought you were in the business of making a GENERAL tool, not in making decisions better left to the individual software package. Our software packages are often used by beta testers, who have to revert to officially released packages. They are also used by consultants and independent programmers, who may need to revert to certain versions used by their customers. We make approximately 250 NEW hardware devices every year, necessitating software updates for tools probably more times a year than most software companies do. So it is not uncommon for customers to only upgrade when they are need to support newer hardware. Therefore we have a number of different versions in wide use at the same time. Of course, we test the downgrade before we release – what do you mean that it CANNOT be tested? Of course it can. When your company makes basic changes like this because you are somewhat short-sighted about different business models, it causes us a lot of problems. I would really like to get a call from someone at your company to convince me that you are committed to supporting your customers and not forcing your philosophy on them unnecessarily.

[lordmaxx]

not necessarily Flexaras policy, more like Microsoft...you know the OS your building software for...sheesh Why upgrade to 2010 anyway unless you actually are planning on using some of the functionality that has been upgraded such as the use of best practices.

Installer drama fun stuff 🙂

[MichaelU]

I understand your frustration, as I see how it's easy to consider the behavior you encountered to be a bug. We don't consider it a bug because it can be overridden, it was an intentional change, and in general we believe the new default will better serve most of our customers. Many of our customers will not be as meticulous as you have been.

In your case, perhaps your customer base and company's business rules require you to support the downgrade path. For this, change the code in OnUpdateUIBefore, as Cary R described.

To clarify my comment about testing, I specifically mean that one cannot test a v2 installation in a v4 to v2 downgrade scenario during the v2 release cycle. What you describe, testing the scenario during the v4 release cycle, is absolutely possible. But one may not always be able to fix problems solely in the v4 installer, and it would be too late to make the v2 install disallow a flawed downgrade. Thus it is a generally accepted practice in most cases to prevent this by requiring a different path one already needs to test: uninstall the later v4 version, then install the v2 version fresh as if a first time install.

[lordmaxx]

Upgrading can be tricky enough with some apps...I wouldn't want to support downgrading! 😛

Now MichaelU check out my multiple install issue a few posts down! got a support ticket in for it and everything, but this one is gonna be close if I have to do some weird developing to actually support it...