Upgrade Problem - Change in Behavior between IA 2009 and IA 2010

[tshepherdkfx]

In InstallAnywhere 2009, rules placed on an action group are evaluated once at the start of the action group. If the rule passes, all steps within the group are executed (like an if statement in a program).

After upgrading to InstallAnywhere 2010, this is no longer true. The action group's rule is executed for every action within the group, as if the rule were specified on each action instead of the group as a whole.

This change in behavior breaks a large portion of our installer because some of our actions within action groups modify variables referenced in the action group rule. It is way too costly (and risky) to find all actions within our installer that modify variables within their action group's rules.

1. Is there a way to configure IA 2010 action groups to behave the same as they previously did?

2. Is this a bug? I don't think it is because the IA 2010 documentation describes the behavior, however, I cannot think why anyone would actually want IA to behave this way. If you really want a rule to be reevaluated for each action, you should put the rule on the action itself instead of relying on this confusing behavior.

If we cannot find a solution to this, we will be forced to roll back to IA 2009.

[pv7721]

The IA 2009 behavior might have been a good thing (evaluating the expression only once), but I guess that the idea behind re-evaluating the initial expression for each action in the action group is just an extra measure for such scenarios like yours: I don't think it's a good idea to have such value changes of IA variables used for action group evaluation... But of course, we need to have a comment from an IA developer.

[tshepherdkfx]

Coming from a developer background, I tend to disagree. It is a common practice in code to check a value, then subsequently change its value.

Here is a contrived example:

String userInput = getUserInput();
if (null == userInput) {
    userInput = "Default value";
    System.out.println(String.format("User did not specify value, using default: %s", userInput));
    somethingElse();
}
...

While you can accomplish the same thing by reordering code, it can lead to badly written code and it imposes unnecessary restrictions on the developer (as in InstallAnywhere 2010's case - forcing me to only assign values as a last action within an action group, or adding additional variables to track state).

[pv7721]

Put it like this, of course you're 100% right! 🙂 I was thinking from my point of view only, as I've only recently discovered the Action Groups and the whole benefit I could really see in it (I remember when it was introduced in fanfare 5 years ago they said it was the feature most user asked:

Action Groups
InstallAnywhere 7 introduces a revolutionary way to design your installers with the introduction of Action Groups. This is by far the most popular feature request Zero G has received from existing customers. Action Groups provide the ability to logically group a set of actions or panels in Pre-Install, Post-Install, Pre-Uninstall and Post-Uninstall. Rules applied to the Action Group affect all the actions or panels it contains. Actions Groups make InstallAnywhere projects more manageable and easier to understand. Available in InstallAnywhere Enterprise Edition only.

And back then the old forums located offered the users the possibility of asking for feature requests, and more users requested a feature, the more chances were there for the feature to be implemented. Unfortunately, those forums are down so no search possibility, but I clearly remember not to have seen this feature anywhere! Instead, features like Undo/Redo or Copy/Paste across projects, those kind of feature which have been asked for years, are still missing!...

So, sorry for the rant, back to Action Groups, have you indeed noticed in the quote above (it's taken from the WhatsNew.htm that came with version 7) it clearly says: "Rules applied to the Action Group affect all the actions or panels it contains." So anyway, when I finally started to use them, the only usage I could see fit for was to group platform specific actions... So having in mind such an usage, it was a little difficult to understand why evaluating the rule for each action (the platform on which it is installing hasn't magically changed between actions, hasn't it?), on one hand, and on the other hand how could you have change the platform value?!? 🙂

Voila, voila... 🙂


And

[tshepherdkfx]

The way it is written in that quote is rather ambiguous. The IA 2010 documentation is much more explicit about it (noting that the rule is evaluated multiple times for each subaction).

My main concern is that the behavior changed between 2009 and 2010 without any sort of option to configure it, and it is preventing us from using the new version without rewriting a significant portion of our installer. Not to mention the testing impact that would have.

[pv7721]

Unfortunately, on a more general note, from my experience (I've started using IA back at version 5.5 back in 2003) that each and every time I've upgrade to a newer version, the upgrade was more or less painful (most of the time it was... more! 🙂 The last time I've upgraded (and I've stopped at IA 2008 VP1) it was such a small thing like a late evaluation of a variable (obviously a not documented change, so it took me a while before I could track down the change, and adapt the project accordingly). Moreover, if you "miss" an upgrade, it gets more complicated if you want to upgrade later, the IA advice was (and maybe still is) for a long time to upgrade to each intermediate version, in order to incorporate version changes into the project.

[jijujacob27]

Hi tshepherdkfx and Vlad,

With InstallAnywhere 2010, it was necessary to make changes to the way rules were being evaluated. For every action, we now evaluate as follows.

RuleResult = (rules present in action evaluated 
        according to the logical operator specified)
  && (rules applied on all parents) 
  && (tags applicable on the action).

When we evaluate the rules of the parents, then we take into hierarchy, parents in visual hierarchy, i.e., immediate parent action groups, etc and then the parents in install hierarchy, i.e., the components and features.

At present there is no configuration parameter to control this behaviour.

While it has been our foremost aim to not cause any migration related issues, we regret the issues caused to you due to the change in evaluation of rules. (now each action's rules being evaluated inclusive of its parents rules & tags).

We would still encourage you to pick up InstallAnywhere 2010 and try out the new features, which we believe would give you more benefits in the longer run.

Thanks,

[jijujacob27]

I would like to provide some clarification regarding my previous post

Please refer to 1.jpg. If we have action groups similar to 1.jpg, the evaluations are as follows.

Note that the “Action Group: inner rules fail” is set with a rule which does fails
Note that the “Action Group: inner rules success” is set with a rule which succeeds

Also note that “Show Message Dialog:a” rules are never evaluated.

The evaluation result is as follows.

Preflight Evaluation (before pre-install starts)
Evaluating rules for InstallSet -- Typical
Evaluating rules for InstallSet -- Minimal
Evaluating rules for InstallBundle -- Application
Evaluating rules for InstallSet -- Typical
Evaluating rules for InstallSet -- Minimal
Evaluating rules for InstallBundle -- Application
Evaluating rules for InstallBundle -- Application
Evaluating rules for InstallBundle -- Help
Evaluating rules for InstallBundle -- Application
Evaluating rules for InstallBundle -- Help
Evaluating rules for Installer -- artist
Evaluating rules for InstallBundle -- Application
Evaluating rules for InstallBundle -- Help
Evaluating rules for InstallBundle -- Application
Evaluating rules for InstallBundle -- Help
Evaluating rules for GhostDirectory -- artist
Evaluating rules for OSHost -- Operating System
Evaluating rules for GhostDirectory -- artist
Evaluating rules for OSHost -- Operating System
Evaluating rules for Installer -- artist
Evaluating rules for InstallBundle -- Application
Evaluating rules for InstallBundle -- Help
Evaluating rules for IntroAction -- Panel: Introduction: Introduction
Evaluating rules for InstallDirAction -- Panel: Choose Install Folder: Choose Install Folder
Evaluating rules for InstallDirAction -- Panel: Choose Install Folder: Choose Install Folder


Evaluation when pre-install
Evaluating rules for InstallDirAction -- Panel: Choose Install Folder: Choose Install Folder
Evaluating rules for ActionGroup -- Action Group: outer
Evaluating rules for ActionGroup -- Action Group: inner rules fail
Evaluating rules for ActionGroup -- Action Group: inner rules fail
Evaluating rules for ActionGroup -- Action Group: inner rules success
Evaluating rules for ShowDialogAction -- Message Dialog: b
Evaluating rules for ShowDialogAction -- Message Dialog: b
Evaluating rules for ShortcutLocAction -- Panel: Choose Alias, Link, Shortcut Folder: Choose Shortcut Folder
Evaluating rules for ShortcutLocAction -- Panel: Choose Alias, Link, Shortcut Folder: Choose Shortcut Folder
Evaluating rules for ActionGroup -- Action Group: outer
Evaluating rules for ActionGroup -- Action Group: inner rules fail
Evaluating rules for ActionGroup -- Action Group: inner rules success
Evaluating rules for ShowDialogAction -- Message Dialog: b
Evaluating rules for ShortcutLocAction -- Panel: Choose Alias, Link, Shortcut Folder: Choose Shortcut Folder
Evaluating rules for InstallSummary -- Panel: Pre-Install Summary: Pre-Installation Summary
Evaluating rules for InstallSummary -- Panel: Pre-Install Summary: Pre-Installation Summary
Evaluating rules for InstallSummary -- Panel: Pre-Install Summary: Pre-Installation Summary