17 replies to this topic

[overlordchin]

So In an attempt to prevent downgrades I attempted to use the ISPreventDowngrade mechanism with the built in error text. It only displays when the version installed is a major upgrade from the version i am trying to downgrade to. If it is a minor upgrade from the version i am attempting to downgrade to; the installer starts to run and no dialogs or errors display it just closes the application. As a work around mechanism I pondered the idea of reading the version out of the registry entry and then comparing it to [ProductVersion] in an install condition.

Stefan implied there was another way to do this with minor up/downgrade in this post: http://forum.install...showtopic=17917

The issue with my thought is that the conditional statement does not appear to like having [ProductVersion] in the statement (it throws an error). If I try to change it to just ProductVersion the conditional reads as regVers < ProductVersion but once you exit the wizard it shows the evaluation of it is "regVers" which would always be true.

Surely there is a better way to go about doing this.

[Stefan Krueger]

[overlordchin]

What I mean is in the IDE if I click on Product Properties and double click on 'Install Condition' (I have 4) A dialog (which i am referring to as the wizard) pops up and shows my 4 conditions. The one in question displays my REGVER which is a property set during a system search in a statement that reads as "REGVER<ProductVersion" without the "" and when I click ok the condition says "REGVER" without the "" with the message set to [IS_PREVENT_DOWNGRADE_EXIT]

[Stefan Krueger]

Seems to work for me, maybe a bug in your version?
You could always go to the Direct Editor, open the LaunchConditions table and edit it there.

[overlordchin]

Ok set it in the direct editor and it seems happy there. I'll give that a try and see if it works. Thanks for the advice.

[overlordchin]

So even if I remove the action in the sequence for ISPreventDowngrade I still get the behavior that i described earlier. The downgrade is prevented but nothing happens. No error message no nothing. AppSearch and LaunchConditions are the first 2 actions in the execute sequence and are after only SetupCompleteError, SetupCompleteSuccess and SetupInterrupted in the User Interface sequence.

they are even before file extraction but seems to take place after regardless. So my conditional never seems to get evaluated b/c find related products seems to happen before it? Findrelatedproducts is way later in the sequence though

attaching screenshots of the sequence for reference

Edited by overlordchin, 26 January 2012 - 19:27.

[Stefan Krueger]

I don't think your setup exits because of the ISPreventDowngrade action. Generate a log file, this will tell you the actual values of the properties, whether AppSearch finds anything, and why (or at least: when) your setup dies.

[overlordchin]

[overlordchin]

ok I turned it on in the registry by following this article:

http://support.microsoft.com/kb/223300


and this is the log file:

[overlordchin]

If I change the ProductCode app search actually happens and my conditional fails and it does not prevent the downgrade. If i dont change the product code as evident by the log it dies before it even starts the appsearch.

I did a diff on the two log files and the new file has these differences:

[overlordchin]

I also tried this to generate a log file and see if there would be any difference:

mysetup.exe /Verbose"c:\testing.log"

no additional log file was created only the one in temp that is MSIxxxxx.LOG which is the one I posted on Friday.

[Stefan Krueger]

If you change the ProductCode it's essentially a new product, which is not installed, and the installer enters first time install mode. If you don't change the ProductCode (but did change the PackageCode, which InstallShield automatically does, and launched using the /v parameter or using InstallSHield's setup.exe) then the product is already installed and the installer enters maintenance mode, using the new msi file.
In the first case it's a major upgrade and the Upgrade table is used. The second case id a minor update and the Upgrade table is not used.

In your log I noticed that you are calling MsiOpenPackageEx. What are you doing there?

BTW the link to how to log a setup is in my signatur

[overlordchin]

I have no idea what causes the MSIOpenPackage or Ex messages. I tried changing the package code and not the product code and got the same behavior that I had been seeing previously. When I looked at the wording on the package code it seems that it changes it automatically if you do a new release. If you are rebuilding the same release (which is the way we have been doing it for ages) it is implied that the package code does not change.

[overlordchin]

Any other ideas out there? I still have no idea what causes that message but in doing some research I have found other products with an install log that looks very similar. The fixes they applied do not work for me or change the output in the log file.

[overlordchin]

So in looking at the tail of the logfile again it looks like its going into silent mode and then immediately closing the msi handle. So it hits silent opens the msi handle sees there is nothing to do and then closes it. Any thoughts as to why?

MSI © (8C:60) [08:42:15:452]: PROPERTY CHANGE: Adding UILevel property. Its value is '2'.
MSI © (8C:60) [08:42:15:452]: Creating MSIHANDLE (1) of type 790537 for thread 3936
MSI © (8C:60) [08:42:15:452]: MsiOpenPackageEx is returning 0
MSI © (8C:60) [08:42:15:452]: MsiOpenPackage is returning 0
MSI © (8C:60) [08:42:15:452]: Closing MSIHANDLE (1) of type 790537 for thread 3936
=== Verbose logging stopped: 1/27/2012 8:42:15 ===

[Stefan Krueger]

Sorry, I have no idea.

[overlordchin]

So I have another installer that actually works correctly and displays the dialog. First it pops up and says this will preform an upgrade do you wish to continue? then if you click yes it throws the error message and prevents a potential downgrade. I generated a log file for it and it looks EXACTLY like the first one i posted with the exceptions of guids timestamps and names of the msi files. It was identical in every other way which explains why the original log file doesnt help diagnose the issue since the one that works correctly has the exact same log output. Just gonna have to start comparing the two for differences. If I figure out what it is I will be sure to post it here.

[overlordchin]

I found it. It actually was using ISPreventDowngrade to prevent the downgrade it just never popped the error dialog or any dialog for that matter. In the upgrade section under the behavior the minor upgrade settings behavior was set to "dont prompt the user just install the upgrade" I flipped it to prompt and tried again. It threw the error right away. Thanks for looking at the logs and all the help. I hope this post helps someone else.