Allow customisation of default install locations for MSIs

[freakboy3742]

What is the problem or limitation you are having?

MSI installers will install into C:\Program Files for All User installs, and into %APPDATA% for per-user installs. These are sensible defaults, but some users may want to customise this default.

In particular, %APPDATA% is a long path, which can cause issues if the code being installed is sensitive to long paths.

Describe the solution you'd like

Add a simple_user_install_path configuration item. Set to false by default, implying the current %APPDATA% based install path. If true, a default per-user install path based on %USER_PROFILE% will be used.

The value provided will only be a default location - the user will still have the option to customise the install path in the install location dialog.

Describe alternatives you've considered

1. Provide full customisation of the user install path (e.g., user_install_path = "C:\some location\My App"). Potentially problematic as there's no guarantee a hard-coded location will exist, although we could allow for WiX variable expansion (so user_install_path = "[%USER_PROFILE%]/My App" would be legal)
2. Provide customisation of the user install root, rather than the full path. This is effectively the same as (1), except that the default Briefcase path construction behavior around appending app name (and optionally project name) would be preserved.
3. Explicitly ask for the environment variable to use as a root. Not sure if there's any real option other than USER_PROFILE or APPDATA that would make sense.

Customising the all user location might also be worthwhile, although the underlying path length question is less of a concern there. If we need to customise all user installs, option (2) (with user_install_root and system_install_root options) might make more sense, so that the suffix applied to the root is consistent.

Additional context

The background question for this feature is "should we be supporting this in the first place?".

On the one hand, Windows best practice dictates always installing into APPDATA. If an APPDATA-based location will cause known problems due to path length, there's an argument that the problem lies with the software itself.

On the other hand, rewriting existing software will rarely be a practical option.

[lrandersson]

I looked into this with AI tool assistance to explore different solutions. A few notes that might be useful here:

• On your "WiX variable expansion could help" point for the alternatives: there's no MSI standard directory that maps to the profile root — ProgramFiles64Folder, LocalAppDataFolder, etc. are the options, and none resolve to C:\Users\<name>. So both simple_user_install_path and the more general "env var as root" alternative would need to set the path at runtime from [%USERPROFILE] (MSI's [%VAR] Formatted-string syntax). It looks convenient for option 3 — any env var the user names should just drop into that syntax.

• A possible gotcha for whoever implements it: INSTALLFOLDER sits under ProgramFiles64Folder, and I believe MSI re-evaluates that the moment ALLUSERS/MSIINSTALLPERUSER are set in InstallScopeDlg — so I think a path override applied at UI init would get clobbered. One approach that I think would work is a sibling Publish on the scope dialog's Next button, ordered after the ALLUSERS/MSIINSTALLPERUSER publishes but before the NewDialog transition:

  <Publish Dialog="InstallScopeDlg" Control="Next" Order="5"
           Condition='WixAppFolder = "WixPerUserFolder"'
           Property="INSTALLFOLDER" Value="[%USERPROFILE]\<app>" />

  (I have not tested this myself)

• Two edge cases I think are worth keeping in mind for the design: I believe revisiting the scope dialog would re-fire that publish and reset a custom path, and I believe InstallScopeDlg doesn't run in quiet mode — so silent per-user installs would likely need a separate execute-sequence action if the default should apply there too. But at the same time, perhaps people using the silent installations are more likely to explicitly list their installation directory?

On the broader "should this be supported at all" question — agreed %APPDATA% is the right Windows default, but for scenarios with conda unfortunately it's very easy to run into issues with long paths on Windows. Even if we have default set to %USERPROFILE it doesn't fix the underlying issue, perhaps it's worth to consider an alternative approach: Check the maximum allowed path length (at least during install time) to not run into any issues.

[freakboy3742]

On the broader "should this be supported at all" question — agreed %APPDATA% is the right Windows default, but for scenarios with conda unfortunately it's very easy to run into issues with long paths on Windows. Even if we have default set to %USERPROFILE it doesn't fix the underlying issue, perhaps it's worth to consider an alternative approach: Check the maximum allowed path length (at least during install time) to not run into any issues.

To confirm I'm understanding this correctly - are you saying that even with a USERPROFILE install path, your use case still has path length issues? At that point, doesn't this suggest that the underlying problem is with the code being packaged supporting long-form paths (such as the way we've fixed this with WiX using \\?\ paths)?

[lrandersson]

Hi @freakboy3742. Sorry I wasn't clear, what I was trying to say was that even if we change the default install path to something that is shorter, there are still use-cases can trigger it (anyone with a very long username for example) - therefore, I'd say even if we change the default path to a shorter variant, the underlying issue is not solved, we are just making it "less likely" to trigger. Does that make sense?
That being said, I still think it would be good to find an option that offers a shorter default install path, to minimize the impact, but perhaps there are other ways to tackle this that in some sense deals the underlying issue.

[freakboy3742]

Oh sure - in the general case, there will always be path issues - that's just Windows being Windows.

My concern is whether providing an easy option to sidestep those path issues is papering over a bigger problem, which is that Windows code does have path length issues, and code that runs on Windows should be accomodating that. The AppData location is intentional (from Microsoft) because it allows for installed apps to be migrated as profiles move across shared desktop environments; circumventing that with "put it in the user's profile dir" is a fix, but I'm not convinced it's a good fix we should be encouraging in the general case.

[lrandersson]

@freakboy3742 I agree!