Custom Install Paths and Major Upgrades

[codesynergy]

Hello,

Here is the problem:

I have two features (FeatureA and FeatureB), each with a set of components. The default install location of Feature A is C:\Program Files\MyCompany\MyAPP (APPDIR). The default install location of Feature B is C:\TestFolderA (TestFolderA_Dir). I have the dialog phase set up such that the “SetupTypeDlg” is displayed, so the user can choose a “Custom” install.

When choosing a custom install, FeatureA and FeatureB are displayed. The install path of FeatureA is set to APPDIR (correct), but FeatureB is also set to APPDIR (not correct), even though all components in FeatureB are added to C:\TestFolderA. If I change the path of FeatureA, then FeatureB’s path is changed to the same path (and vice-versa). So, it appears both feature installation directories are tied to APPDIR, but FeatureB should be TestFolderA_Dir.

1.png (23.63 KiB) Viewed 10915 times

So, I go back into AI and see that the feature directory is set to APPDIR (even though all of it's compoenents are in TestFolderA_Dir). If I click the “…” button and try to select C:\TestFolderA (TestFolderA_Dir), I see:

3.png (11.39 KiB) Viewed 10915 times

So, I open up the properties of C:\TesetFolderA and try to change the identifier to all caps, so I can select it for the feature Directory:

4.png (13.72 KiB) Viewed 10915 times

However, it doesn’t let me change the identifier. I try changing TestFolderA_Dir to all caps in the table editor, but that doesn’t seem propagate to the feature install directory. So, I open the AIP in notepad++ and change all instances of TestFolderA_Dir to TESTFOLDERA_DIR, and now I can select TESTFOLDERA_DIR for the feature installation directory. At this point, everything seems to work for clean installs. FeatureB now installs to TESTFOLDERA_DIR, and the files are installed to the correct directory.

However, I then run into the following issue. If I perform a clean install and use custom installation paths, during a major upgrade, the custom path for FeatureA (APPDIR) is persisted, but the custom path for FeatureB (TESTFOLDERA_DIR) is not. Not sure if it matters, but I’m displaying the SetupType/Custom Setup dialog during major upgrades, so the user can change the paths if they want to.

Hopefully it’s clear what I’m trying to accomplish here:
• Have multiple features that might have their own installation paths (outside of APPDIR).
• Allow the user to change those installation paths in the “Custom Setup” dialog.
• Persist those installation paths during major and minor upgrades (minor upgrades seem to be working fine at this point). But, still allow them to change the paths if they want to (not super important, but nice to have).

How is the best way to accomplish this?

After doing some research, along with the tests above, I’ve reached the conclusion that, by default, windows installer does not carry over installation paths of features during major upgrades. And, the only reason APPDIR is carried over is due to custom logic implemented by AI (the “Use original installation path when upgrading” option). Would that be an accurate statement?

If that’s the case, I suppose the only option is to write any custom installation paths (other than APPDIR) to the registry during install, then read them in during a major upgrade. Does that sound like the right approach?

Also, why can’t I change the folder identifier to all caps? Having to do it in notepad++ is kind of annoying.

Thanks for the help!

[Catalin]

Hello,

In order to set a folder for a feature, a property based folder must be used.

For instance, you can create in "Install Parameters" page a new property. The drawback to this is the fact that you can not set, in "Install Parameters" page, a property that points to another property.

By default, your path looks like this:

Code: Select all

C:\TestFolder

However, since not on every machine there might be a C:\ volume, it would be nice to use a property here (e.g. WindowsVolume).

However, as stated above, this is not possible.

Here is how we can work this around:

- create a new property, like this:

Name: TEST_FOLDER
Value: leave empty
Comment: add any comment here

In "Files and Folders" page, please create a new "property based" folder and as the base property, select the earlier created one (TEST_FOLDER).

Move all your files here.

Now please go to "Custom Actions" page and add a new "Set installer property" custom action, with sequence. The custom action should look something like this:

Property: TEST_FOLDER
Value: [WindowsVolume]\TestFolder

Schedule this custom action before the "Search" action group, in the "Wizard Dialgs Stage".

This way, the location will be set as per your desire.

In what regards this:

Persist those installation paths during major and minor upgrades (minor upgrades seem to be working fine at this point). But, still allow them to change the paths if they want to (not super important, but nice to have).

You can achieve this by setting the property of your folder as persistent. To do so, please go to "Install Parameters" page, double click on your property and check the "Set persistent property" option.

Hope this helps.

Best regards,
Catalin

[codesynergy]

Hi Catalin. Thank you for the response.

In order to set a folder for a feature, a property based folder must be used.

There are two issues I have with this solution:

1. This results in an unorganized list of folders in the "Files and Folders" view. Compare "MyFolder1" with "TESTFOLDER":

1.png (13.04 KiB) Viewed 10900 times

When you are looking in the "Files and Folder" view, it's very easy to understand where "MyFolder1" installs to. But, with "TESTFOLDER", you can't easily tell.

• Regular folders (like "MyFolder1" in the above screenshot) work in all scenarios except major upgrades with custom paths. So, this seems like an unnecessary workaround for that one scenario.

• APPDIR works, so why don't other folders work? Although, I just found out that APPDIR_64 doesn't (details at the bottom).

The benefit of the solution you proposed is that you are able to persist the values of the property to upgrades without much extra work (AI seems to do the work for you). After reading the documentation, it sounds like "Set persistent property" writes the values of the property to the registry, so they can be read in during upgrades, which leads me to my proposed solution:

1. Add the folders as you normally would, but change the property/identifier associated with them (only the ones that you are allowing the user to set the path) to be public (all caps).

• On install, write these paths to the registry (I used HKLM\Microsoft\Windows\CurrentVersion\Uninstall\[ProductCode]).

• During a major upgrade, use the Application Search feature to search for SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\[OLDPRODUCTS]\<path> and read the values of our installation directories into their respective properties.

• Since you are using [OLDPRODUCTS], you have to move the "AppSearch" and "AI_AppSearchEx" custom actions (via Table Editor) to execute after "FindRelatedProducts".

The benefit of this solution is that you get to keep the clean folder structure in the "Files and Folders" view. The downside is, you have to implement the logic (using built in AI functionality) to read and write the registry entries with the paths. But, this is what the "Set persistent property" seems to do anyways.

Thus far, my solution seems to be working. However, I'm still not sure why I can't change folder identifiers/properties from within AI:

2.png (7.89 KiB) Viewed 10900 times

I feel like I've been able to do this in older versions of AI, but now I have to do it through notepad++. This makes me think there is a specific reason why AI doesn't let me change it...

It sounds like there is room for a feature/enhancement here:

• Allow folder identifiers/properties to be changed. Allow the developer to change the name and/or just make it public (all caps).

• Add a similar option to "Set persistent property" to folders. This option would make the the folder property public, write it to the registry on install, and read in the value on upgrade. So, basically, you get the functionality described in the solutions suggested above with the click of a single checkbox.

Also, I found a somewhat related issue. I have 32-bit and 64-bit installations in the same project. This means I have APPDIR and APPDIR_64:

3.png (69.32 KiB) Viewed 10900 times

APPDIR_64 is set to "Install folder content into the parent folder". And, I have the feature directory (for the 64-bit version of the feature) set to APPDIR_64 (APPDIR\APPDIR_64). After installation (clean install), HKLM\Microsoft\Windows\CurrentVersion\Uninstall\[ProductCode]\InstallLocation is set to the default path of APPDIR_64, instead of the custom path entered by the user on the "Custom Setup" dialog. This seems like a bug, and it causes issues with the paths during upgrades (I believe the installer carried over the path in \InstallLocation during the major upgrade, which is wrong if the user entered a custom path during the clean install). So, I basically had to use the work around mentioned above: save the value of APPDIR_64 to the registry during install, and read it in during major upgrades.


Thoughts?


I know that's a lot of text to digest. Thanks for reading it =)

Thanks.

[Catalin]

Hello,

First of all, I would like to start by saying that I do not believe all the additional work is worth just for making the folder structure in the "Files and Folders" page be more intuitive.

If the new developer of the project is confused by that, there are few ways of pointing him in the right direction:

1. when selecting the property based folder, its path is shown in the application

path.png (62.31 KiB) Viewed 10894 times

2. in addition to that, notes can be added to your project that can be later viewed by new developers

notes.png (234.92 KiB) Viewed 10894 times

In what regards the reason behind not being able to modify the "Identifier" (especially with only uppercase characters) is to avoid the desynchronization of the tree-like structure (there are some strange scenarios when this happens). Long story short, it is not a good practice to have two directories with a child relationship between them have their identifiers written in all caps letters. This is the reason why, when creating a property based folder, it is automatically added at the bottom, as a standalone element (not as a child element).

Of course, this can be "hacked" around by either modifying the XML file or by changing the identifier from the "Table Editor" page. However, I would advise against it.

In what regards the APPDIR_64 folder, I am not quite sure I understand the scenario. Could you please give me some more details (e.g. a test case which I can follow in order to reproduce this issue)?

Hope this helps.

Best regards,
Catalin

[codesynergy]

In what regards the reason behind not being able to modify the "Identifier" (especially with only uppercase characters) is to avoid the desynchronization of the tree-like structure (there are some strange scenarios when this happens). Long story short, it is not a good practice to have two directories with a child relationship between them have their identifiers written in all caps letters. This is the reason why, when creating a property based folder, it is automatically added at the bottom, as a standalone element (not as a child element).

Could you go into a little more detail on when this issue might occur? I went back and verified that this was allowed in AI 14.3 (we recently upgraded from). We had made heavy use of the ability to make these properties public (all caps). Changing to property-based folders would be a significant change to our project. I have not noticed any issues so far. But, the fact that you are recommending against it is a little worrying.

In what regards the APPDIR_64 folder, I am not quite sure I understand the scenario. Could you please give me some more details (e.g. a test case which I can follow in order to reproduce this issue)?

Now that I know making the folder properties public is purposely not allowed, I'll have to revisit this. This might be an issue on our end.


Thanks!

[Catalin]

Hello,

Could you go into a little more detail on when this issue might occur? I went back and verified that this was allowed in AI 14.3 (we recently upgraded from). We had made heavy use of the ability to make these properties public (all caps). Changing to property-based folders would be a significant change to our project. I have not noticed any issues so far. But, the fact that you are recommending against it is a little worrying.

Please ignore my last thread in what regards this.

Upon further investigations, we found out that this was actually a bug introduced by one of our devs. We are already working on a fix for this. After the fix will be implemented, you will be able to rename the directory ID to all uppercase letters.

I will update this thread as soon as the fix will be implemented.

Best regards,
Catalin

[codesynergy]

Please ignore my last thread in what regards this.

Upon further investigations, we found out that this was actually a bug introduced by one of our devs. We are already working on a fix for this. After the fix will be implemented, you will be able to rename the directory ID to all uppercase letters.

I will update this thread as soon as the fix will be implemented.

Thank you. Also, since this is the case, please reconsider the issue I described earlier. I've attached an example project that replicates the issue:

• Build "Install64".

• Run the install, choose a custom path, and finish the install.

• Notice that HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\<product code>\InstallLocation is set to the default path instead of the custom path.

• Rebuild the installer with a newer version number and product code (to force a major upgrade)

• Perform another custom install and notice that the default install path is being used instead of the custom install path that your application was installed to.

In the project file, it's worth noting:

• I have a 64-bit application directory folder (APPDIR_64_DIR) that is set to "Install folder content into the parent folder" (which is APPDIR).

• The install path of the 64bit feature is set to APPDIR\APPDIR_64.

If you change the feature install path to APPDIR, this fixes the issue for major upgrades. However, it breaks minor upgrades. If you then perform a minor upgrade, it will change HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\<product code>\InstallLocation to the default location of APPDIR, instead of the custom path you used.

So, it's not clear to me if I'm supposed to set the feature install directories to the parent folder or the child folder when using the "Install folder content into the parent folder" option. Either way seems to result in a bug.

Thanks.

[Catalin]

Hello,

First of all, thank you for the provided files.

I have tested this and I could indeed replicate the behavior.

First of all, please keep in mind that the InstallLocation registry entry refers to the APPDIR location, which most probably you did not modify in the CustomizeDlg dialog.

Also, another thing to be kept in mind here is that the upgrade process can not know about the value of your property if the property is not persistent.

To fix this, you can proceed as it follows:

- first of all, please go to "Files and Folders" page and uncheck the "Install folder content into the parent folder" option

- now please go to "Install Parameters" page and create your property there, as it follows:

Name: APPDIR_64_DIR
Value: whatever value you'd like as the default value (e.g. C:\)

Check the "Set persistent property" option.

Important: Make sure this value is included in the 64-bit build.

Now, during the upgrade, the value from the previous installation should be used.

The above is basically the same as working with property based folders, the only different thing being the folders structure (as it is a child folder for the "Application folder").

Hope this helps.

Best regards,
Catalin

[codesynergy]

First of all, please keep in mind that the InstallLocation registry entry refers to the APPDIR location ...

Ok, that confirms what I was thinking.

... which most probably you did not modify in the CustomizeDlg dialog.

Well, I tested two scenarios: In AI, feature install path set to APPDIR (parent) and feature install path set to APPDIR_64_DIR (child). In the former test, by changing the feature install path in the CustomizeDlg, I did set APPDIR. In that scenario, major upgrades work, but minor upgrades do not (for the 64-bit install).

Also, another thing to be kept in mind here is that the upgrade process can not know about the value of your property if the property is not persistent.

Since APPDIR is written to the registry as mentioned in the quote above, any feature that uses APPDIR should carry over the custom install path right? In other words, isn't APPDIR made persistent by default (either by default MSI behavior or custom Advanced Installer behavior)? That fact that the 32bit build works seems to confirm this.

If I run the 32bit build from that same project, both major and minor upgrades carry over the custom path (everything works as expected). So it appears APPDIR is being carried over, as long as you aren't using a child folder. I thought the "Install folder content into the parent folder" option in the child folder would, essentially, set the install path of that child folder to the parent folder (in my example project, that's APPDIR). So, if APPDIR is being carried over for the 32bit build (where the files are directly in the parent folder), why doesn't the 64bit build carry the APPDIR folder path over for the files in the child folder (as long as the feature install path is set to APPDIR)?

The whole reason I made the properties of the child folders public in my original project, was so I could set the feature install paths to that public property. Otherwise, the only install path you can set your features to is APPDIR (since it's public by default). This causes problems when you want to install a folder outside of APPDIR (ex: C:\web).

I understand now that all folders other than APPDIR won't be carried over (which seems like an oversight (Microsoft?)), but that's a whole other conversation). However, APPDIR seems to be a special case.

Let me ask this. Setting aside the issues of major/minor upgrades for the moment, if I'm using the parent-child folder configuration (which is suggested in the Advanced Installer documentation), what is the "proper" way to set up the folders and feature install path in the attached project (32-bit and 64-bit builds in the same project):

• Create a child folder with the "Install folder content into the parent folder" selected?

• Do I make the child folder property/identifier public?

• For the 64-bit build, do I set the feature install path to the parent (APPDIR) or the child (APPDIR_64 if I make the child property public)?

From my perspective, there appears to be at least one bug here tied to the child-parent configuration of APPDIR, since everything works for the 32-bit build in my test project. If you are going to give the user the ability to support 32-bit and 64-bit installs in the same project via the child-parent folder relationship (along with the "Install folder content into the parent folder" option), then I think you should make it work in all scenarios (major and minor upgrades). What I'm seeing here is that the parent-child feature that Advanced Installer has is not viable for all installation scenarios (major/minor upgrades) that use custom paths.

At the end of the day, It sounds like what I want to do can't be done. So, I'll have to use the property based method you recommended (or my own method that I described above). I would suggest a feature/enhancement in a future version of Advanced Installer that addresses this scenario. I think it should be easy (like... clicking-a-check-box-easy) to carry over custom install paths. Ideally, this would be an option for all folders (even outside of APPDIR).


Thanks!

[Catalin]

Hello,

Since APPDIR is written to the registry as mentioned in the quote above, any feature that uses APPDIR should carry over the custom install path right?

Yes, you are right here.

In other words, isn't APPDIR made persistent by default (either by default MSI behavior or custom Advanced Installer behavior)? That fact that the 32bit build works seems to confirm this.

Indeed, this is true. By default, when creating a new Advanced Installer project, you can find in the "Registry" page two values - Version and Path.

In addition to that, as you could see, the default behavior of the MSI (I believe) is to write its' InstallLocation in the registries as well.

I thought the "Install folder content into the parent folder" option in the child folder would, essentially, set the install path of that child folder to the parent folder (in my example project, that's APPDIR)

It does that, but that does not mean the two folder identifiers are the same. Your child folder may have the same path as the parent, but this does not mean the properties of the both have the same flags (e.g. persistent).

We can think of this as it would be with two variables. Let's consider we have two variables, "a" (an integer) and "b" (a string). If:

a=5

and

b="5"

we could say that "b" has inherited the value from "a", but that does not mean "b" was turned into an integer, it is still a string.

It is the same with the properties here in our case. If the property of the child folder inherited the value from the parent folder, that does not mean it also inherited its' flags/properties.

Otherwise, the only install path you can set your features to is APPDIR (since it's public by default)

As long as the property is public (so its value can be passed from Wizard Dialogs Stage to Install Execution Stage), you can make it persistent as I have showcased in my latest thread.

However, APPDIR seems to be a special case.

We made it "special" because, by default (when creating a new AI project), the "Use original installation path when upgrading" option is checked in the "Upgrades" page. However, this does not mean you can not make other folders behave the same.

Do I make the child folder property/identifier public?

Yes, this will be needed so the value of the property will be written in the registries (a registry entry is written during the "Install Execution Stage" and only public properties' values are carried over from "Wizard Dialogs Stage" to "Install Execution Stage")

For the 64-bit build, do I set the feature install path to the parent (APPDIR) or the child (APPDIR_64 if I make the child property public)?

Here, I would advise treating the "APPDIR_64" folder as a standalone folder (not as a child) and making its property persistent as I've showcased in my last thread.

I would suggest a feature/enhancement in a future version of Advanced Installer that addresses this scenario. I think it should be easy (like... clicking-a-check-box-easy) to carry over custom install paths.

As I have previously mentioned, we will improve this so you can change the identifier of your folders to public properties. After being able to do so, you will just need to set the property as persistent (I believe this is "easy" enough).

Hope the explanation helps.

Best regards,
Catalin

[codesynergy]

Hope the explanation helps.

It does! Thank you very much for addressing all my questions. I think I have an idea on how to proceed now. Thanks!

[Catalin]

You are always welcome!

I am really glad you found the information helpful.

Best regards,
Catalin

[Catalin]

Hello,

This has been fixed in version 17.1 of Advanced Installer, released on May 27th, 2020.

Best regards,
Catalin