Menu
▾
▴
#656 WixUI_Advanced: Never install files in [LocalAppDataFolder]
Software should never ever be installed in [LocalAppDataFolder]. It need to be installed in [AppDataFolder] as this is the only folder that is kept in Roaming Profile environments.
[WixUI_Advanced.wxs]
<customaction id="user-content-WixSetDefaultPerUserFolder" property="WixPerUserFolder" value="<span>[LocalAppDataFolder]</span>Apps\[ApplicationFolderName]" execute="immediate"></customaction>
Discussion
Traditionally, the roaming profile is kept small because of the cost of syncing. The MSI SDK explicit says to use LocalAppDataFolder. You can override the default with a custom action to set WixPerUserFolder, scheduled after the existing WixSetPerUserFolder.
Can you share the link to this documenatation, please? It must be a big missunderstanding of the documentation or at least it misses the roaming profiles, folder sync exclusion or folder redirection policy as background.
Yes, Roaming profiles have folders that are synced. This is correct, but roaming profile paths are redirected to a server share in a correct roaming profiles environment. There are GPO policies to redirect many default windows folders like documents and appdata - out of the box. You may have seen them already if you have opened a GPO.
AppData is normally redirected to a user home on a file server (best practice). The reason is that the folders don't need to be synced any longer. They stay in this location for all times and are not synced from the fileserver to client pc with every logon and logoff.
In opposite to "roaming app data" folders the "local app data" folder and all subfolders are explicitly excluded from syncing between clients and servers to save network bandwith and time on logon/logoff. This is very useful as there are normally data located that can get lost on a logoff (aka TEMP files that run faster on local disk than on network).
Now there comes another policy in place - truncate local profiles on logoff. This policy removes all user profiles from local disk after a user logged off. This is highly required if you have users changing their PCs very often. They just sit on a new desk every day. Files are not kept on disk and also don't fill the disk over time.
What happens now is - the application installed into LocalAppDataFolder get's truncated from disk, Leaves all registry stuff behind and the users will loose the application with every logoff.
This is how roaming profiles are implemented in enterprise. Only for the reason that some bad Google developers install it's Chrome into this location doesn't make it correct.
Chrome isn't the only example; ClickOnce also uses local profiles too. Feel free to file a feature request to make this an option in WixUI_Advanced.
You can see this request as "feature request" if you like this more, but it's clearly a critical BUG.
I don't care here about other buggy projects I'm not using and I have no idea what ClickOnce is, but this type of bug can be seen in many buggy projects where developers have no idea about roaming profiles and may just follow wrong Google developers who have no understanding about some important Windows basics - all with brain turned off.
All software with this bugs is broken and this need to be reported as bugs.
I disagree that it's a bug -- there's plenty of documentation and history to indicate the local profile is preferred. But I agree it makes sense to support both local and roaming profiles, hence the feature request. Anyone is free to implement it and submit a patch/pull request.
I already asked for this "plenty documenation" links as they must be unclear or contain information that is missing roaming profiles aspects! Can you share this any links to this incomplete documenation, please? Otherwise I need to say this docs do not exist, but I personally know the "keep roaming small" is 100% correct per past documenation, but this is for sure no reason to install an application into the "local app data" folder. This is plain wrong interpretation of this sentence.
Can you also shed some light on what you meen with "local profile is preferred", please? I don't get it... it's only correct for everything that can get lost after a logout when the "document and settings\%username%" folder is whiped from disk, but an application shouldn't get lost. Temp folders and stuff inside such folders should get lost on logout. No harm at all for temp stuff, but loosing an application is 100% plain wrong. Always keep in mind that users don't have an idea what a roaming app folder and a local app folder is. They cannot make a decission on install time.
I'm really asking me if developers implementing this type of broken stuff - have any understanding of how windows profiles work. Their one person local profile box is not the one that we are talking about here.
Telling a roaming profile folder should be kept "small" is no reason to place an app in local apps folder - that are deleted - on logoff and never synced back to a server nor kept on the PC. The user will not sit on front of the same PC again tomorrow (e.g. computer pools in universities - 100 computers for 10.000 users).
Again - this folders get LOST and this is not special - this is the recommended configuration in multiuser computers with roaming profiles. This is clearly a bug if the application get's lost on logoff.
Roaming profile is not appropriate for all applications/environments either (e.g., big apps, tiny quota). Making the profile type a choice that the developer or network admin can configure (e.g., via property or transform) makes the most sense to me. Until someone implements such a feature, however, there is an easy workaround.
The default is extremely unlikely to change in WiX v3.x because of servicing implications.