Closed lars-berger closed 2 weeks ago
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
@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
.
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?
@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.
I suspect this was a bug way back in the v3 timeframe. I can even see that there was an attempt to fix it https://github.com/wixtoolset/issues/issues/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.
@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.
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:
Once you try to mix and match these, you're heading off into unsupported territory.
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.
WiX Version
5.0.0
.NET or MSBuild or Visual Studio Version
.NET 8.0.303
HeatWave Version
-
Windows Version
Win10 22H2
Repro Repo
https://github.com/snoopwpf/snoopwpf/commit/32c5eb28d641d5324ef3cb3da84df6a7167e9dfa
Repro Steps
The particular commit in the url above is the upgrade from WiX
3.14.1
to5.0.0
that causesDesktopFolder
to incorrectly point toC:\Users\Public\Desktop
rather thanC:\Users\<MY_USER>\Desktop
. Repro repo is not mine.Actual Result
DesktopFolder
standard folder evaluates to thePublic
user rather than the current user.Excerpt from 3.14.1 installer logs:
Versus equivalent logs in 5.0.0 installer:
Expected Result
Installing to the
C:\Users\Public\Desktop\
has been described as an unintuitive experience by users.Is there a way to achieve the old behavior in WiX v5?
Acknowledgements