How do I get around application scope settings being read-only?

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.

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.

An old question, but I provide this answer to help anyone attempting to implement Simon P Stevens' answer related to the ConfigurationManager class since I wasn't sure how to do it being a novice with settings.

One of the first realizations was that the 2 Settings files in my C# project (made difficult because the typical one under Properties was there, but empty) were combined into the single .config and split between different ConfigurationSections. I thought that was why ConfigurationManager.AppSettings and ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None) both kept returning 0 keys.

It took a lot of trial and error to realize that most of the ConfigurationManager references deal with the default appSettings and that was different than applicationSettings which is what Settings uses.

I ultimately found the following:

Select the right ConfigurationSectionGroup/ConfigurationSectionClient, cast to SettingsSection, get the setting, and set the XML InnerText (e.g. below):

// this gets the applicationSettings section (and the inner section 'inoBIBooks.My.MySettings')
Configuration config = WebConfigurationManager.OpenWebConfiguration("/" + targetvdir);
ConfigurationSectionGroup applicationSectionGroup = config.GetSectionGroup("applicationSettings");
ConfigurationSection applicationConfigSection = 
applicationSectionGroup.Sections["inoBIBooks.My.MySettings"];
ClientSettingsSection clientSection = (ClientSettingsSection)applicationConfigSection;

// set a value to that specific property
SettingElement applicationSetting = clientSection.Settings.Get("BIDB_Username");
applicationSetting.Value.ValueXml.InnerText = "username";

// without this, saving won't work
applicationConfigSection.SectionInformation.ForceSave = true;
// save
config.Save();

This is pulled from:
Access section 'applicationSettings' (not 'appSettings') in config file from setup
and
Save and reload app.config(applicationSettings) at runtime

Look here: Best practice to save application settings in a Windows Forms Application

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.