Reg value not being included in all builds

[shelmers]

This is driving me crazy! I'm sure I'm missing a setting somewhere but can't find it.

My installer has two builds, one for Standard and one for Professional.

It also includes one main feature and two sub-features:

• The main feature is included in all builds and contains several dozen components;

• the Standard_ONLY sub-feature contains two components and is only installed with the Standard build;

• the Professional_ONLY sub-feature contains four components that are only installed with the Professional build.

So far, so good -- almost everything is packaged in the correct build.

The exception is a pair of registry values that are written to an existing registry key. Both values are in the main feature and should, therefore, be included with all builds. However, even though several dozen other components in the main feature are included in every build, these two reg values are included in Professional builds but NOT in Standard builds.

Where else might there be a flag or condition that is preventing these values from being part of Standard builds?

[Catalin]

Hello,

Unfortunately, I can not say for sure why this happens.

In order for me to further investigate this issue, could you please forward me the following resources:

- a copy of your .AIP file

- a verbose log of the installation process

by e-mail at support at advancedinstaller dot com?

Best regards,
Catalin

[shelmers]

Thanks, Catalin. I wasn't expecting you to know precisely what was wrong! But I hoped there might be an obvious place or two for me to look for something I had missed.

I'll send the requested files to you shortly.

[Catalin]

Hello Scott,

First of all, please accept my apologies for the delayed reply, but we were quite busy lately.

Thank you for the provided files.

I have further investigated this and I think I found the reason why your registry entries are not written in the standard edition.

If you go to "Registry" page and right click on any of your registry entries ("StenchiPath_2016" or "TemplatePath_2016") --> "Go to component" (or simply press F8 button), this will redirect you to the "Organization" page, on the component that is created for your registry entry.

As you can see, the component is part of the "PRO Only" feature, basically, this component will only be installed if the "PRO_Only" feature is installed.

If we go one step further (select the "PRO_Only" feature) --> under "Builds" section, we can notice that the "Include feature only in the selected builds" option is used and that only your "pro" builds are selected ("PRO_EXE" and "PRO_MSI").

Therefore, this is the reason why the registry entries are not included in your standard edition.

Hope this helps.

Best regards,
Catalin

[shelmers]

Catalin,

Thanks for your suggestion but I'm not certain that's the source of the problem. The "StencilPath_2016" and "TemplatePath_2016" entries are not under the PRO_only feature, they are part of a long list of components that are included in every build -- note the level of indentation under the TaskMap feature in this screen capture. In fact, all components from "AI_ExePath" through "Visio" are successfully included in every build with the exception of the StencilPath and TemplatePath.

For emphasis, I've highlighted in yellow the only four components that are actually part of the PRO_Only feature.

As I mentioned in my email to you, I did discover that the StencilPath and TemplatePath values are being written to
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\16.0\Visio\Application
Is there some sort of redirection going on for the STD installer that is not happening for the PRO installer?

Thanks,
Scott

[Catalin]

Hello Scott,

First of all, thank you for your followup on this and for the explanation.

Yesterday I've been investigating this towards the end of the shit and due to tiredness, I somehow overlooked the part of the e-mail where you have stated about the registry redirection.

Please accept my apologies for that.

I have started the investigations again today and this time I dived deeper into the problem. I have stripped down the .AIP file you sent me and tested this first hand. I can confirm that the scenario completely reproduced on my machine as well.

Now, just to make things clear: the standard installer is the one where the behavior is correct (I mean, in both scenarios, the behavior is correct - will explain this a bit later). Since the package type for your setups is "32-bit", it is normal that it gets redirected in the WOW6432Node.

However, the difference between the two builds is actually the installation type:

- in your standard edition, the installation type is set to "Per-machine if user is administrator, per-user otherwise". Basically, this will write in the HKLM hive.

- in your pro edition, the installation type is set to "Per-user only (with administrator rights required)". Basically, this will write in the HKCU hive.

Upon further investigation, I have found something that honestly I would have never thought about:

Apparently, the registry redirection does not happen in all keys in the HKCU hive.

For more information about this, please have a look on the following:

- StackOverflow thread - Registry redirection does not happen for HKEY_CURRENT_USER

- Microsoft article - Registry Keys Affected by WOW64

Hope this helps!

Best regards,
Catalin

[shelmers]

Thank you -- you found the problem! I was certain that I was overlooking a setting somewhere in the installer that was causing the problem but couldn't find it.

Thanks also for explaining more about registry redirection; it's a subject I don't know enough about and have been confused by in the past.

A product suggestion based on my error: you might consider making the build selection more obvious in the UI. The list on the ribbon of the Install Parameters and Themes pages is pretty subtle -- it's easy to miss it and then run into the problem I did where the settings were unintentionally different in different builds. The Feature list on the Files and Folders and Registry pages is similarly obscure.

Thanks again. I've set all builds to Per User, which solves my immediate problem, and I'll spend some time learning more about redirection and per-machine installs.

[Catalin]

You are always welcome, Scott!

I am really glad I could help.

A product suggestion based on my error: you might consider making the build selection more obvious in the UI. The list on the ribbon of the Install Parameters and Themes pages is pretty subtle -- it's easy to miss it and then run into the problem I did where the settings were unintentionally different in different builds. The Feature list on the Files and Folders and Registry pages is similarly obscure.

Thank you for your feedback on this. I can indeed agree on the fact that the build selector is not the most obvious thing, but unfortunately, I am not aware of any method in which we can make it more obvious. Do you have any suggestions here? Maybe make it a little larger - what do you think about this?

Best regards,
Catalin

[shelmers]

Unfortunately, I don't have a specific suggestion. Making the selectors larger and more prominent would probably help a bit. It would be great if they were located in the main working area of the app rather than on the ribbon, but I don't think that's practical. So I guess we're back to leaving them where they are but making them more visible. Thanks for asking; sorry I can't be more helpful.

[Catalin]

Thank you for your feedback on this, Scott!

I have forwarded the suggestion to our development team and we will see what can be done.

Best regards,
Catalin