user.config file not being created but app.config is?

Question

My program has some settings built in which all have a User Scope. However when the program launches it only creates the AppName.exe.config file, which contains the settings .

When saving a setting later on during runtime, it creates the user.config file (which previously didn't exist) in the AppData/Local/AppName/ location, but that file only contains the saved setting.

Why does this happen? Why won't it create the user.config or use that on startup if it exists?

Elane

+1 from me. Please post back the solution you come to, as this is a good question IMHO. There's quite a few work-arounds out there for sharing an app.config file between distinct apps (ie not just classes/forms in the same app domain) and these will probably pick up whatever user.config(s) are present when the app starts (which would address your concern re multiple files), but nothing I can find directly addresses the situation of getting the up-to-date shared configs where the user.config file(s) may have been updated by one of the sharing apps at run time. – Piliferous

Answer 1

From Application Settings Architecture at MSDN:

1. Application-scoped settings can be stored in either the machine.config or app.exe.config files. Machine.config is always read-only, while app.exe.config is restricted by security considerations to read-only for most applications.

2. User-scoped settings can be stored in app.exe.config files, in which case they are treated as static defaults.

3. Non-default user-scoped settings are stored in a new file, user.config, where user is the user name of the person currently executing the application. You can specify a default for a user-scoped setting with DefaultSettingValueAttribute. Because user-scoped settings often change during application execution, user.config is always read/write.

What you're seeing first is (what you've called) your "built in settings" being stored as (what Microsoft calls) "static default" user-scoped settings, which get stored in app.exe (as per 2).

And then when you write back your settings at runtime, they're treated as "non-default" user-scoped settings, and they're being written to user.config (as per 3) hence why only then do you see the user.config file created.

In short, there's no need for a per-user user.config file, as long as the user-scoped settings are the same (defaults) for everyone.

Piliferous

Is it not possible to just have it push them all to that file? As I have a service and a form using them, and what happens is once the form updates a value, it makes this user.config file, and then the service still pulls values from the app.config file :S – Elane

I'm not sure that you're meant to be able to "share" a single configuration (either a single app.config, or combined with one or more user.config files) between two distinct apps. AFAIK there's no way for the LocalFileSettingsProvider to know that the config file it's bound to has been updated by an external source. I suspect you'd need to implement your own derivation of SettingsProvider (or maybe there's something out there on the 'net that does what you need). – Piliferous

Or, you could experiment with LocalFileSettingsProvider.GetPropertyValues or LocalFileSettingsProvider.Initialize to see if either of these "refresh" their cached settings with ones read fresh from the combined app.config/user.config files. Doing this just prior to accessing the setting might just work around the problem: it might recognise the new user.config file. – Piliferous

You did answer my question btw with explaining how the app.config is made, and what its doing. However I am not able to find a relatively simple solution to hook into my user.config file so I am going to just use a local database alternative I think. – Elane

@Mombassa If a DBMS is overkill, and the "refresh" experiments I suggested above didn't work, I think I'd probably just resort to a single shared XML file with all users' settings serialised within (assuming that would work and be appropriate under your circumstances). That way, whenever the service needed to check the settings, it would just need to de-serialise the XML into your custom settings class and you'd always have the refreshed version (but perhaps this is what you meant by "local database alternative" ;-). Please tick to accept my answer if you feel it addressed your question. – Piliferous

Sorry I thought I had accepted your answer dude! I am using the DB alternative :) – Elane