You are here

Best practice configuration management

3 posts / 0 new
Last post
Last seen: 2 years 10 months ago
Joined: 2015-01-29 21:16
Best practice configuration management


I am currently developing an application which should be portable or non-portable (like many apps here).

I am now thinking about a best practice for "configuration management", e.g. how the app handles its configuration on startup.

Since I read the "what is a portable app" link Smile and I don't want to mess up with windows annoyances like registry etc., my approach is currently the following:

* read the configuration file xyz.cfg in the program's directory.
* if it is not found, try to read config file from user's %APPDATA% or %LOCALAPPDATA% and act according to it.
* if it is found, first handle the options here. If a security option in there says "no normal user is allowed to have an own configuration", break. if it is allowed, read user specified config file from %APPDATA% or %LOCALAPPDATA% (btw., what's the difference and what should when be used? :)) and add additional configuration from there.

Is there anything I am missing? Are there some tutorials/best practices/howtos regarding elemental software design like this?


Ken Herbert
Ken Herbert's picture
Last seen: 30 min 51 sec ago
Joined: 2010-05-25 18:19
Couple of things

AppData vs LocalAppData

%APPDATA% (User\AppData\Roaming) is for data you would link to a user. In a corporate network-type setup the data stored here is transferred from PC to PC with the user profile so it is always there no matter which workstation the user logs in to.

%LOCALAPPDATA% (User\AppData\Local) should only be used for data that is either tied directly to the machine or is too large for the speedy syncing of the user profile.

Thus you should use %APPDATA%. If your app happens to find itself in that kind of environment it will be ready, and if your app never sees a corporate-style network then there is no difference to the end user.

Data location process

First of all even if your app is installed to %ProgramFiles% on a non-admin account it will still (kind of) be able to write to its own folder.

Windows (pre-Vista) allowed apps to write to %ProgramFiles% without issue. It is now considered bad design in apps for Vista and up, but for legacy purposes modern Windows handles apps trying to write to %ProgramFiles% without admin privileges by letting the app think it can, but silently redirecting these changes to %LocalAppData%\VirtualStore\Program Files\, so your app will always think it can read/write its files to its own folder, even though they are actually somewhere else.

Another idea (the way I do it for my own apps):

  1. Default to app's own directory
  2. If command line parameter for the data path is present use that instead


  • Works perfectly in normal portable situations (just writes to its own folder)
  • Works perfectly in a PortableApps package (Launcher passes %PAL:DataDir% on command line)
  • Works as an installed app (installer sets up desktop and/or start menu shortcut which pass %AppData% on the command line)


  • The one way users can break this unknowingly is to create a shortcut directly from the exe in %ProgramFiles% instead of from the start menu or desktop. Then they will be invoking the app with no command line parameter, and will thus save files in %ProgramFiles% via the VirtualStore. The app will still work fine, but it will look like they have lost all of their data in the process (this is not an issue for me personally because I don't actually provide installers).
Last seen: 2 years 10 months ago
Joined: 2015-01-29 21:16
Thanks a lot for claryfing

Thanks a lot for claryfing this!


Log in or register to post comments