Mar 21, 2011
11:13 AM
Interresting idea, didn't think of that since I was using automatic update entries until now. But: 1) Does this also work when two upgrade entries would match? For example, 3.5.0 adds another condition I'd like to skip that way, and someone updates from 3.3.0 (skipping the 3.4.0 stuff, going right up). Do I get both, do I have to code that differently, or do I only get the highest matching one? 2) What happens when the automatic update would have done a minor update, and not a major one? Doesn't this affect the way the whole update process is executed; and possibly make my changes obsolete (since it does a full uninstall or something anyways)? I was kinda assuming that I could simply get the version (or at least Label) from the small dialog saying "This setup will perform an upgrade of Product v3.3.0" and work with that. Edit: For now, I'm using a Major Upgrade entry with "Detect only" set to true to add the property, along with my existing Automatic Upgrade entries. Seems to work for now, but still feels a bit odd.
... View more
Mar 21, 2011
07:27 AM
I am currently working on a new Version of a Setup (3.4.0) where several new input parameters (in this case: an additional path) were introduced. Now, during upgrade, I want to check whether the version I am updating from is < 3.4.0 and show an additional dialog to force the user to input the new path. However, I'd like to skip this step when I'm updating from >= 3.4.0 (at some point in the future, at least), because the path should already be there in those cases. The only property that sounded remotely correct during an upgrade attempt with /L*v logging was "VersionHandler", but its value "3.01" never appears anywhere in my old Setup (nor does it match the old Version number of 3.3.0). Is there a property supplied by default that I can use, or do I have to roll my own? The Setup is a Basic MSI one; I know how to skip Dialogs based on Property Values and I could even use InstallScript to set my own Property based on a few method calls - conversion to an InstallScript Setup is not feasible at this point.
... View more
Labels
- Labels:
-
InstallShield 2009
Mar 22, 2010
03:19 AM
Guess a lot of Trial&Error ever leads to some solution, the one way or the other. Here's what I did for now: - Defined a new Property "IS_UPGRADE" (must be all upper-case for some reason, using "IsUpgrade" does not work), initialized to 1 by default. - Set the Property to 0 in case of InstallWelcome and MaintenanceWelcome, but leave it 1 when _IsMaintenance = "Remove" (since NOT REMOVE does not work either) - Changed the condition to "(&Server = 3 OR !Server = 3) AND (IS_UPGRADE = 0)". Either way, I'm still wondering if IS provides any built-in properties for that, its a bit odd that I seem to have to define those things myself. Any Docs on that, anywhere?
... View more
Mar 19, 2010
08:02 AM
I have a Basic MSI Setup which does some file modifications (plain-text config file, no XML unfortunately) which has to receive a few values entered by the user. This is done using InstallScript called at the end of the Exec Sequence, "After InstallFinalize" - this works in general. Now I noticed that something is wrong during Upgrades...the values are supposed to be entered by the user, while the Upgrade does not ask for any input. As a result, the config file was overwritten with its default values - this should be disabled. After some playing around (someone suggested "AND RESUME" over here), it seems I even broken it for Modify and Install itself, because the condition never applies now. This is what I have right now: Function Name | ModifyConfig Return Processing | Synchronous In-Script Execution | Immediate Execution Execution Scheduling | Always execute Install Exec Sequence | After InstallFinalize Install Exec Condition | (&Server = 3 OR !Server = 3) AND NOT RESUME AND NOT PATCH AND NOT REMOVE Server is the Feature which triggers the config file modification; it should run when Server is either to be installed (in case of &Server = 3, applies to Installation) or already installed (in case of !Server = 3, applies to Modify). Adding this Resume/Patch/Remove thing apparently broke it afterwards (by chance, it does apply to Upgrade scenarios since the latter 3 conditions just evaluate to false, by coincidence doing what i want). Some testing revealed that Resume/RESUME and Patch/PATCH are not set (or not evaluating to true; unless they use some other casing) when doing either Upgrade or Modify. Since the condition is obviously wrong, could anyone shed some light on how it should be done correctly?
... View more
Labels
- Labels:
-
InstallShield 2009
Latest posts by BhaaLseN
Subject | Views | Posted |
---|---|---|
726 | Mar 21, 2011 11:13 AM | |
2588 | Mar 21, 2011 07:27 AM | |
710 | Mar 22, 2010 03:19 AM | |
3413 | Mar 19, 2010 08:02 AM |
Activity Feed
- Posted Re: Get Version of old Product during Update? on InstallShield Forum. Mar 21, 2011 11:13 AM
- Posted Get Version of old Product during Update? on InstallShield Forum. Mar 21, 2011 07:27 AM
- Posted Re: Run custom Action during Install and Modify, but not on Upgrade? (IS2009, Basic MSI) on InstallShield Forum. Mar 22, 2010 03:19 AM
- Posted Run custom Action during Install and Modify, but not on Upgrade? (IS2009, Basic MSI) on InstallShield Forum. Mar 19, 2010 08:02 AM