Comments (8)
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
from issues.
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
.
from issues.
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?
from issues.
@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.
from issues.
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.
from issues.
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.
from issues.
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:
- 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
- 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.
from issues.
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.
from issues.
Related Issues (20)
- TouchFile fails due to 64-bit initialization HOT 2
- Error 2318: File does not exist HOT 8
- Page Not Found: /documentation/
- ExtensionValidation: Early check on valid Table Name
- .NET Core bootstrapper shows a popup to download .NET runtime despite having it included as a prerequisite HOT 5
- Validate that generated GUIDs don't change (and stay compatible across WiX versions)
- Before/After Sequencing 'helper' (for Custom Actions)
- RemoveFoldersEx doesn't force add RemoveFiles Standard Action to MSI to allow it to work HOT 1
- Adding "Id" attribute to BootstrapperApplication breaks the bundle
- Naked `File`s can result in WIX0095 errors in mysterious circumstances
- Page Not Found: /schemas/v4/wxs/ui HOT 2
- Patch build crashes without media HOT 1
- Increase build parallelization
- Temp directory issue after wix v3.14.1.8722 upgrade
- Patch build tries to set non-nullable field to null when deleting row
- Setting InstallLocation, InstallSource in the bundle ARP entry HOT 1
- DisplayInternalUICondition doesn't work correctly HOT 3
- Cache events returns wrong action type
- Page Not Found: /docs/fiveforfour/
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from issues.