User-selectable OVERRIDECACHE

[mihai]

Hi,

I'm having this requirement where I need to insert the "$COMPANY$\$TITLE$" before the GUID in the installer cache path, so that the folder can be easily identified. However, setting OVERRIDECACHE based on the user-selection of "All Users / Current User" in the setup (so that I know whether it ends up in %APPDATA% or %ProgramData%) seems to be too late, losing the component selection etc., as the Help warns about.

Is there a way to achieve this? I wonder how it works internally, in that it doesn't have any issues when it changes the installer cache path itself, based on the user-selection of "All Users / Current User"?

Thanks,
Mihai

[FrancescoT]

You may try the "OVERRIDECACHE" pre-defined variable. It allows to change the default installer cache location.
https://www.installaware.com/mh5/desktop/predefinedvariables.htm?rhsearch=OVERRIDECACHE&rhsyns=%20

[mihai]

That's what I'm doing and explained, please re-read.

[FrancescoT]

The "OVERRIDECACHE" pre-defined variable must be sequenced very early, and preferably, at the very beginning of the setup main script. Otherwise, the new cache location will be not propagated correctly.

Of course, with setting the variable so early in the script sequence, there is no chance to detect successive changes of ALLUSERS variable during script execution.

An alternative may be with running the setup in silent mode from command line, and with explicitly passing OVERRIDECACHE and ALLUSERS as command line parameters. It will work in this case. Due the SILENT MODE, ALLUSERS will not re-assigned by the script, and this allows to resolve ALLUSERS very early as well. However, this approach will never work running an interactive setup process. Unless, you embed your setup inside a wrapper setup package, which doesn't install itself, but it just runs your real setup as you would do silently from command line.

Hope this helps you.

[mihai]

How come InstallAware can do it internally? Just trying to understand the limitation.

Also, would moving the "All Users / Current User" up-front in the wizard sequence help? There are probably still some things defined even before that that should be redefined, right?

Thanks.

[FrancescoT]

After an override, the setup engine is re-initialized, which has side effects such as the loss of previously declared setup features, persistent variable values, and so forth.

It would help moving the "All Users/Current User" selection up-front. However, this should be done as early as possible and before of any declared setup features, persistent variable values, and so forth. Which is not very nice, honestly.

That said, and if you really need to override the cache location, I would certainly do a try using a wrapper as I told you previously.

Hope this helps you

[mihai]

OK, it's clear what I would have to do, thanks!

I hope you don't mind me insisting on this, but I'm going to ask it again (third time's a charm?): how come InstallAware can do it internally? Is it automatically re-declaring the setup features etc.? I'm referring to the fact that there are no issues when the "All Users / Current User" is changed mid-wizard, in a setup that doesn't use OVERRIDECACHE. With this in mind, why the limitations for OVERRIDECACHE?

and if you really need to override the cache location

Yes, I really need to - business call. But, as I mentioned, I only need to insert a prefix, something that might actually be a good feature request for a variable called CACHEPREFIX, to specify a sub-path to be prepended to the GUID. Thoughts?

[FrancescoT]

In all honesty, I really don't know how I can possibly be even more clear.

After an override, the setup engine is re-initialized, which has side effects such as the loss of previously declared setup features, persistent variable values, and so forth.

This means that "previously declared setup features, persistent variable values, and so forth" are LOST. These doesn't get re-declared, they simply may not exist anymore or previously assignments may become null (as these was never assigned previously).

Of course, there are no issues when OVERRIDECACHE doesn't get assigned. In this case the setup engine doesn't get re-initialized.

It doesn't make any difference a new CACHEPREFIX variable. Because this would have the same identical limitations. Due the fact that this would end with overriding the cache location, and exactly as the OVERRIDECACHE already does.

Hope this helps you.

[mihai]

Of course, there are no issues when OVERRIDECACHE doesn't get assigned. In this case the setup engine doesn't get re-initialized.

How come, because the cache location can be changed by the end user later in the wizard, at "All Users / Current User"? Forget about OVERRIDECACHE when I'm asking this.

It doesn't make any difference a new CACHEPREFIX variable. Because this would have the same identical limitations. Due the fact that this would end with overriding the cache location, and exactly as the OVERRIDECACHE already does.

It actually does make a difference, because one can change the sub-path (i.e. CACHEPREFIX, say to "MyCompany/MyProduct") very early on, then relying on the InstallAware internals to deal with the actual base path ("All Users / Current User"). Edit: it would be like editing the GUID in Project Options and pre-pending a string.

Hopefully we're getting on the same page?

[FrancescoT]

How come, because the cache location can be changed by the end user later in the wizard, at "All Users / Current User"? Forget about OVERRIDECACHE when I'm asking this.

I understand perfectly what you mean. Yes, In this case the Engine does it internally. However, currently if you want to override the internal cash location, this can be exclusively done via OVERRIDECACHE), and the engine gets re-initialized.

At any rate and alternatively to the setup wrapper approach I suggested you previously, you may eventually also try with re-launching the setup from the running interactive instance of your setup.

In other words, when the setup runs interactively ($SILENT$ = FALSE), this should only complete the setup wizard to collect all necessary data. Finally, all collected data + OVERRIDECACHE should be then passed as command line parameters, while invoking from the setup script a new non interactive instance of your setup (ex Run Program $ENGINECACHE$ /s <parameters>).

It actually does make a difference, because one can change the sub-path (i.e. CACHEPREFIX, say to "MyCompany/MyProduct") very early on, then relying on the InstallAware internals to deal with the actual base path ("All Users / Current User"). Edit: it would be like editing the GUID in Project Options and pre-pending a string.

Yes, you are correct and this may be a future option.

[mihai]

Yes, In this case the Engine does it internally.

Thanks for the confirmation.

However, currently if you want to override the internal cash location, this can be exclusively done via OVERRIDECACHE), and the engine gets re-initialized.

Got it. Maybe this can be improved in the future, even with added restrictions for when OVERRIDECACHE would be allowed.

alternatively to the setup wrapper approach I suggested you previously, you may eventually also try with re-launching the setup from the running interactive instance of your setup

Yes, got it, smart & neat workarounds, thanks.

Yes, you are correct and this may be a future option.

Great! Where can I make an official feature request for CACHEPREFIX, so that it can be tracked appropriately?

[FrancescoT]

I have submitted such request already. Unfortunately there is no way to track its status, and for now, I cannot give you any anticipation about its release or possible availability.

[mihai]

Understood & thanks for submitting the feature request!