tags:

views:

385

answers:

2

What use are they if they cannot be altered from their default values anyway? Rhetorical question.

First, what's the best way to circumvent the Settings system and write to the application scope settings file directly (security issues in the next paragraph)? XmlReader/XmlWriter?

IIRC, if an application tries to write to its Program Files folder, Windows Vista and 7 does some magic to prevent that. I suppose I need to call UAC to elevate and I must put that fancy shield icon on my application's Options window's OK button and so on. Link to a quick how-to?

Alternatively, you may tell me that what I'm trying to do is stupid and I should store my alterable application scope settings somewhere else altogether.

A: 

If you change them to "user" settings they can be changed in code, and when you call Save() they will be saved to a user.config file in the current users local settings folder.

Obviously, this means they can be different for every user. Generally, global application settings that are the same for every user aren't modified in code because a change that one user makes will effect everyone else (hence the app settings are read only).

If you don't want them to be user scoped, take a look at the ConfigurationManager class. This will allow you to manually read and write to .config files. Remember though that the c:\program files\ folder is protected and normal users won't have access to it (this will result in UAC prompts or failure in vista/win7). Consider carefully how you will handle it, and remember that any change to an app.config will affect all users.

There is no location in windows that all users are guaranteed to have write access to.

Simon P Stevens
But that is exactly what I want! User A modifies something, and User B doesn't have to repeat that modification.
CannibalSmith
A: 

Look here: http://stackoverflow.com/questions/453161/best-pratice-to-save-application-settings-in-windows-application/453390#453390

The ApplicationSettings class doesn't support saving settings to the app.config file. That's very much by design, apps that run with a properly secured user account (think Vista UAC) do not have write access to the program's installation folder.

You can fight the system with the ConfigurationManager class. But the trivial workaround is to go into the Settings designer and change the setting's scope to User. If that causes hardships (say, the setting is relevant to every user), you should put your Options feature in a separate program so you can ask for the privilege elevation prompt. Or forego using a setting.

bitbonk