Our client only allows applications to be installed when logged in as Admin. The application that needs to be installed has to be installed for the current user of the machine. The application installs fine, my problem comes in when i need to drop a config file in the appdata/user profile folder of the user. As this is where they want it, currently the config is being dropped on the admin profile on installation. How do i get past this, is there a way for me to check on installation if there are other profiles and maybe write to them, but this feels dirty.
Cross-Reference : A related issue is when you have a settings file that regular users can't write to. This is a list of approaches for eliminating that condition: System.UnauthorizedAccessException while running .exe under program files .
I will just summarize what others have basically mentioned, fleshing things out a bit trying to make a "little reference".
Maybe have a look at the mentioning of the Win10 ransomware protection feature below for an important tidbit on how this Windows change can affect deployment of user-profile files .
There are many ways to get files deployed to each user on a computer, but there are many drawbacks and problems with most of the approaches. In all honesty there are problems with all approaches, in one form or another.
Below is a list of some common deployment approaches first, and then a mention of some "cloud-based approaches". In the future this discussion may become irrelevant as settings are entirely cloud based and synced on the fly and deployment may switch entirely from per-machine to per-user based deployment. We will have to wait and see how it turns out.
HKCU\\Software\\MyCompany\\MyApplication\\Version\\HKCU_KeyPath = [ComputerName]
in order to make the key path value a "moving target" so that self-repair is triggered reliably when the user logs into a new computer (despite roaming profiles bringing in existing HKCU settings).HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Terminal Server\\Install
and then written to each user's HKCU hive when they log in. This may conflict with ActiveSetup - for all I know. I have never had the chance to test it. Packaging for Terminal Server is typically done by a dedicated, specialist server team.With data storage seemingly moving to the cloud the common approaches to data file deployment may quickly become obsolete.
I don't like option 3 (Self-repair) and option 4 (Active Setup) anymore, although I have used them many times - and they do work when done right. They are, however, not immune to roaming profile issues (files not being copied in place on all systems the user logs onto) and lacking access to the MSI installation source when repair is running - which can cause deployment problems. There are also frequent complications during major upgrades with reset settings, and self-repair fails on terminal servers. Self-repair could fail for installation to the user-profile because of ransomware protection or security software interference. The command line specified in option 4 (Active Setup) could be buggy and wipe out data (for example you enable the wrong flag for the msiexec.exe repair and force overwrite the settings file by accident - this is often not discovered until it is too late and the damage is done). And there are further issues that escape me right now. Both approaches have similar, but slightly different limitations.
I more and more prefer cloud-based approaches to make local (and isolated) user settings files a thing of the past - but I rarely have been able to deploy things this way. These cloud approaches may face problems with firewall / proxy issues and network connectivity problems though - and probably several other things I am not aware of yet (now developers will quarrel with DBOs rather than deployment specialists, etc... ;-)). Distributed computing has its fallacies: https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing . Also: in cloud-based approaches it still may be a good idea for applications to allow settings to be backed up to disk, so some file management is obviously still needed - or do you just export a couple of database tables? Also: if you install a trial version of your application, you may want it to be able to function without network connectivity at all - in case the user is behind a very tight firewall. It is a very expensive mistake to make to not allow your user to test your application's features because of a technicality.
The great benefit of options 1 and 2 is that they will work even if the original installation media is missing when the repair is triggered. This is particularly important for home and small-office deployment where deployment may happen rather haphazardly without a centralized package share. You can work around this problem (missing source MSI) by using caching methods to cache the whole MSI on the system during the installation (available in Installshield, I haven't checked WiX or Advanced Installer).
Don't create the config file on installation, check and see if it exists on program run, if not then create it in the running users profile folder. If it does exist, then use the data in it and continue on.
You can make this work with the repair feature. The big picture is that file was installed for one user at install time at a user profile location, and in a per-system install that will mean that the file will be missing when another user logs on to use the app. It depends on the structure of the MSI components, features and shortcuts, but starting the app with an advertised shortcut may result in the missing file being installed with a self-repair. Obviously this requires the source MSI to remain available.
However the safest way to get the file installed for any new user is to explicitly call MsiProvideComponent passing the ProductCode of the MSI, Feature name, Component id and so on as described in the documentation. As the docs say, this will install the component if it's missing, again requiring the source MSI to be available.
This functionality deals with the case where there are user accounts that haven't been created yet, so obviously you can't yet put files in their profile folders.
Whether it's the best approach compared to others will depend on specific details of the app.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.