Upgrade from 3.14.1 to 5 causes incorrect `DesktopFolder` about issues

[bevanweiss]

Do you have excerpts from those two install logs which show what the ALLUSERS setting is configured to?
It is probably also worth using Orca to (manually) compare the directories specified in the two installers. Given the authoring shown in that commit, I can't see that there is any difference to the Desktop location (which Orca should confirm)... so I'm more suspecting that the ALLUSERS property is ending up different

https://learn.microsoft.com/en-us/windows/win32/msi/desktopfolder

For certain values of ALLUSERS it might depend on the MSIINSTALLPERUSER property also

[lars-berger]

@bevanweiss

These properties are present in the logs for the 5.0.0 installer, whereas they aren't defined in the 3.14.1 installer.

Property(C): ALLUSERS = 1
Property(S): MsiRunningElevated = 1

It's also worth noting that most user-specific directories behave the same, like FavoritesFolder, LocalAppDataFolder, and PersonalFolder (which in my case point to C:\Users\larsb\Favorites\, C:\Users\larsb\AppData\Local\, and C:\Users\larsb\Documents\ in both installers). But DesktopFolder, and also StartMenuFolder, StartupFolder, now point to global user folders in 5.0.0.

[bevanweiss]

The value of the ALLUSERS property, at installation time, determines the installation context.

• An ALLUSERS property value of 1 specifies the per-machine installation context.
• An ALLUSERS property value of an empty string ("") specifies the per-user installation context.

With that ALLUSERS=1 it's doing a Per-Machine install, so it makes complete sense that it's installing to the Public / All Users folder. You'll want to not have ALLUSERS set to 1.

I think you'll want to set the PackageScope Type to "perUser"
https://wixtoolset.org/docs/schema/wxs/packagescopetype/

Are you sure that the original source you referenced was really the original source?
i.e. there wasn't an InstallScope="perUser" somehow missing from version control on the Package element?

[lars-berger]

@bevanweiss Tried out the build script at that commit for myself, and am reproducing the behavior of the 3.14.1 version correctly pointing DesktopFolder to C:\Users\<MY_USER>\Desktop\.

Interestingly, the Install button has an elevation shield in the 5.0.0 version but not in the 3.14.1 version (screenshot). Both versions are installing to C:\Program Files (x86) and prompt UAC after clicking Install.

perUser would correctly point the DesktopFolder to the current user. I'm unfortunately forced to install to C:\Program Files in my use case due to UIAccess, however, this comes with the downside of desktop shortcuts being installed to the Public user which is different from the WiX 3 behavior.

[bevanweiss]

I suspect this was a bug way back in the v3 timeframe.
I can even see that there was an attempt to fix it #4532
But it looks like the defaults were neglected... and the (v3) defaults themselves appear to be conflicted.
Having the default InstallScope be a per-User install, but also that by default the InstallPrivileges was elevated, and could install (somethings) in per-Machine scope.. not an ideal situation.

I'm unsure that WiX v4+ would go back to that inconsistency (it's definitely more a @barnson / @robmen kind of query though).

I would expect however, that if you're installing to a perMachine location, that the application should be available to all users, and hence any desktop shortcut to it should be shown to all users (i.e. in the public desktop location).
You can see through all the Microsoft documentation (https://learn.microsoft.com/en-us/windows/win32/msi/single-package-authoring) that they never intended for there to be this half-Machine, half-User Folder hybrid.
It was always supposed to be either specific to a single user (each user could install their own copy if they wanted), or installed by a computer administrator and made available for all users.

[lars-berger]

@bevanweiss

It's a bit surprising that it's a bug because the current behavior is unfortunately even more inconsistent than previously.

In a 5.0.0 per-machine install there's a strange mix of directories that point to shared vs. current user directories (with a lot more directories pointing to the current user):

Property(S): DesktopFolder = C:\Users\Public\Desktop\
Property(S): TempFolder = C:\Users\larsb\AppData\Local\Temp\
Property(S): CommonFilesFolder = C:\Program Files (x86)\Common Files\
Property(S): ProgramFiles64Folder = C:\Program Files\
Property(S): CommonFiles64Folder = C:\Program Files\Common Files\
Property(S): AppDataFolder = C:\Users\larsb\AppData\Roaming\
Property(S): FavoritesFolder = C:\Users\larsb\Favorites\
Property(S): NetHoodFolder = C:\Users\larsb\AppData\Roaming\Microsoft\Windows\Network Shortcuts\
Property(S): PersonalFolder = C:\Users\larsb\Documents\
Property(S): PrintHoodFolder = C:\Users\larsb\AppData\Roaming\Microsoft\Windows\Printer Shortcuts\
Property(S): RecentFolder = C:\Users\larsb\AppData\Roaming\Microsoft\Windows\Recent\
Property(S): SendToFolder = C:\Users\larsb\AppData\Roaming\Microsoft\Windows\SendTo\
Property(S): TemplateFolder = C:\ProgramData\Microsoft\Windows\Templates\

It's an unfortunate pain for devs who need to install to the C:\Program Files directory, which then has the side-effect of slightly changing some of these directories to the common Public user directory. If this was truly a bug in v3, then perhaps it'd be more intuitive to add directory ids like CommonDesktopFolder (similar to the current CommonAppDataFolder) for those who actually want to target these directories.

[bevanweiss]

All of these are Microsoft provided paths (they behave identically in v5 as they did in v3 for the same installer properties).
https://learn.microsoft.com/en-us/windows/win32/msi/desktopfolder
https://learn.microsoft.com/en-us/windows/win32/msi/tempfolder
https://learn.microsoft.com/en-us/windows/win32/msi/commonfilesfolder
https://learn.microsoft.com/en-us/windows/win32/msi/programfiles64folder
https://learn.microsoft.com/en-us/windows/win32/msi/commonfiles64folder
https://learn.microsoft.com/en-us/windows/win32/msi/appdatafolder
https://learn.microsoft.com/en-us/windows/win32/msi/favoritesfolder
https://learn.microsoft.com/en-us/windows/win32/msi/nethoodfolder
https://learn.microsoft.com/en-us/windows/win32/msi/personalfolder
https://learn.microsoft.com/en-us/windows/win32/msi/printhoodfolder
https://learn.microsoft.com/en-us/windows/win32/msi/recentfolder
https://learn.microsoft.com/en-us/windows/win32/msi/sendtofolder
https://learn.microsoft.com/en-us/windows/win32/msi/templatefolder
https://learn.microsoft.com/en-us/windows/win32/msi/commonappdatafolder

It's the Microsoft Installer engine that is changing the values of where these directories are reported based upon whether the installer is 'perUser' or 'perMachine'. so the 'inconsistent' paths are all Microsoft, you can see that they do document that in the links. They specify which are impacted by ALLUSERS, and which always point to Current User directories.

I would have expected a whole bunch of validation errors for an MSI authored as the Snoop is.
https://learn.microsoft.com/en-us/windows/win32/msi/ice38
https://learn.microsoft.com/en-us/windows/win32/msi/ice57
https://learn.microsoft.com/en-us/windows/win32/msi/ice91
https://learn.microsoft.com/en-us/windows/win32/msi/ice-105

For an MSI to be valid as per Microsoft rules, it's supposed to not have any ICE violations.
WiX is intended as a tool to assist with the authoring of compliant installers, so deliberately breaching ICE constraints would not be desirable.

As Microsoft documentation indicates, the two supported options are:

1. Per User install, where all installed items would be contained within a users personal folders. Multiple users could each install their own versions, they would not require Local Administrator (elevated) privileges
2. Per Machine install, where all installed items would be contained within globally accessible folders. The Local Administrator (elevated) would do the installation, and it would be available for all users.

Once you try to mix and match these, you're heading off into unsupported territory.

[barnson]

MSI has some Common... directory properties but it's currently working as documented. You'd need to take up a feature request with Microsoft to get different behavior.