We Keep Coding

Editing/Modifying C# Application Settings

The .NET configuration settings feature is not as flexible as I would like.
If I understand Application Settings correctly, I am limited as to when I can change/edit settings. In C#, Application Settings are divided into two different types or scopes ("Application" and "User"), but both have limitations in regard to how they can be changed or modified. The following table demonstrates the differnce:
SCOPE: | EDIT AT DESIGN-TIME: | EDIT AT RUN-TIME: | EDIT BETWEEN SESSIONS:
---------------------------------------------------------------------------------------
User | Setings.settings | Settings.Default.Save() | *Not supported*
Application | Setings.settings | *Not supported* | edit app.exe.config
Is there any "built-in" settings functionality that will allow me to edit settings by all three mechanisms? One of the primary motivations for using a configuration file is to allow users to change default values without re-building the source code (as can be done with Application-scoped settings). However, the user shouldn't be forced to edit a .config file; they should also be able to make a change at run-time that persists across settings (as can be done with User-scoped settings). Surely there must be some sort of mechanism that provides both functionalities.
BOTTOM LINE: Why can't Application Settings (app.exe.config) be edited at Run-Time? That would solve all my problems. I understand that this could cause problems for users who share the same machine. But who does that anymore?
POTENTIAL WORKAROUND: Is there anyway to change the default storage location for the User Settings config file into a non-hidden folder?
UPDATE (for clarification):
What I'm saying is that I want to be able to change a default setting at Design-time, at Run-time, or in-between sessions (i.e., by editing a config file). But when using the built-in C# persistence mechanisms provided by Settings.settings, I must choose at most 2 out of the 3. Am I missing something? Is there another alternative that I am not aware of?
[Use Case: I want to store a "default" database name for the connection string, but I want the user to be able to specify a different database at runtime (and thereby become the "new" default for that user). But I also want to be able to over-write the default in the config file without re-running or re-building the application.]
[BETTER Use Case: (In response to comments)
I have a computational model with a config file that contains the default values for parameters in the model. User A starts up the model and decides to change the value of several of the parameters. That change needs to persist for all future sessions for that user (i.e., Edit at RunTime). Subsequently, that user wants to share that modified configuration file with his team (via version control repository, for example, or email). This would allow User B to update her default parameter values (to match User A's) without having to manually change them in the application (i.e., Edit Between Sessions). All of these mods should happen AFTER Design-Time.]
*I realize that I can "technically" edit user-scoped settings in the app.exe.config file located in the hidden AppData folder, but this is a hidden file and not all users may have sufficient privileges to view it. (BUT see "Potential Workaround" above.)

All you need to do is combine the two techniques!
At the start of a session, read the configured setting from a config file, and store it into a global static variable (or any form of persistence) that is writeable.
Then when a user decides to change this setting, simply change the value of the setting.
public static Program {
public static string ConnectionString { get; set; }
void Main(string connectionString) {
ConnectionString = connectionString;
}
}
public class SomeOtherClass {
public void SomeOtherMethod () {
Program.ConnectionString = "new value";
}
}
This is just a very trivial example of how you'd use this. Note that instead of passing the string as an argument to the program you'd probably choose to read the default value from the application settings. You'd also probably store the user-configured connectionstring into some sort of database so that for each user the database could be different.

What if you tried the following in the case study and you might generalize it?
As long as the user can change the default Database name, so this Key should be defined under the User Scope and not the Application scope
Upon installing the application which I assume a windows application, and on the first run, check if the user.config has the value of Database name, if yes proceed in loading the application, otherwise, move to step 3.
Show the user a screen with the database name has a default value and the user can change the settings and make sure to do some validations here, after finishing the settings page, store them in the user.config file, so your application on the next run, it will find the required settings in order to run normally.
For admin privileges, you can show a button to change the settings at run time.
I use this technique for all applications that needs from the user to define some important details like " where to store images, the database name , the connection string, ... etc"
hope this will give you a hint or something

Clickonce application not seeting AppSettings

I have a Full trust, online only, click-once application that relies on settings in the App.config --> appSettings collection.
Once published, the first time the application is executed, the settings are read and everything works fine. If I close the application and run it again, the items that are in appSettings are no longer there and appSettings.Count is equal to 0.
I have set the app.config as "Content" and to "Copy Always".
Any Idea what could be causing the items in appSettings to disappear? or a way to get around this?
Also, please note that the settings are only being read, and being used to determine how the application is run. We're not trying to manipulate the settings.

I guess you are using the settings wrong.
First of all, you need to mind the difference between application and user settings. Application settings are constant and can not be changed from your code (for example default values, connection strings, etc.). User settings are for settings that change when the application runs, usually because there is some sort of Settings dialog in your application.
Secondly, you need to access them properly. People tend to (and I don't know why) use things like ConfigurationManager or other stuff to access settings. It is far easier and less error-prone to use Properties.Settings.Default.SettingName for both application and user settings.
Changing a user setting would read like this:
Properties.Settings.Default.SettingName = settingValue;
Properties.Settings.Default.Save();
The call to Save is important, as otherwise the change will not be persisted.
Thirdly: No need to change the way app.config is included in your project. By default it will be renamed to applicationname.exe.config and will always be included in your output unless you say otherwise. The same goes for the ClickOnce installation: It will be included by default. You may actually break things if you play with this or the ClickOnce deployment settings for app.config! Revert them to default and leave them alone.
Now one case where the settings will be lost and reverted to defaults is when you update your application. In this case you will have to migrate your settings from the previously installed version, otherwise the user settings will be overridden with the default values from the installation. What you do to migrate the settings is:
Define a user setting named SettingsUpgradeRequired (name doesn't really matter - should be self-explaining, however) with a default value of true in the settings designer. Then, when your application starts, you do this:
if (Properties.Settings.Default.SettingsUpgradeRequired)
{
Properties.Settings.Default.Upgrade();
Properties.Settings.Default.SettingsUpgradeRequired = false;
Properties.Settings.Default.Save();
}
This makes sure a migration of the settings only occurs when required. SettingsUpgradeRequired will only be true upon the first installation (in which case Upgrade does nothing) and after an update of your application, because - as I said - by default the configuration from the ClickOnce installation will override the previous configuration until you perform the upgrade.

Save values over end of program in application C#

I want to save User-Settings with Visual Studio 2015, that don't reset after ending the application. For example you can choose the language and on the next startup of the application the settings are loaded. Is this possible without using external Files, StreamWriters and so on?

You could use application and user settings as described in this MSDN tutorial
There is a distinction between app settings which are readonly at runtime, but valid for all users on the machine, and user settings, which can bei changed, but are only valid for the respective User.
You can create them via VS in the project properties -> settings. You use them in Code via
var x = Properties.Settings.Default.MySetting;
See the tutorial for further Details.

User settings - different location for each application version?

I'm developing an application that saves various user settings (e.g. window locations, options, preferences). This is done using the syntax
Properties.Settings.Default.setting_name = "xxx";
Properties.Settings.Default.Save();
and
var x = Properties.Settings.Default.setting_name;
Here is an example of the underlying settings file path:-
C:\Users\user_name\AppData\Local\company_name\exe_name.vsh_Url_kxrjspzszls01bmlnkpeuf5cutfdioia\1.0.0.0
The problem is that each time I build and release a new version of the software, users are losing their settings. This is presumably down to the fact that the application exe version number is being included in the file path, so each time a new version is installed it starts over with a new, empty settings folder? Fortunately we're still in the dev phase so it's only a couple of internal users at present.
What's going on, and is there a way around it?
I'm also concerned because we have an existing product out in the field, and are due to release a new version shortly. I'm panicking that all these users will lose their settings and preferences when they upgrade.

So based on other SO questions and articles found on the web, I've written this short method that I now call during application startup:
private static void CheckForUserSettingsUpgrade()
{
if (!Properties.Settings.Default.UserSettingsUpgradeRequired)
{
return;
}
Properties.Settings.Default.Upgrade();
Properties.Settings.Default.UserSettingsUpgradeRequired = false;
Properties.Settings.Default.Save();
}
For this to work there must be a user-scope setting called UserSettingsUpgradeRequired with a default value of True.
After an upgrade (resulting in a new settings file being created) this setting's value will of course be true. In this scenario the above code will import all settings from the previous settings file (if any), set this upgrade flag setting to false, then save the changes. After the next upgrade, the flag's value will revert to true, and the process will repeat itself.

Releasing WinForm Program Updates

I'd like to release some updates for a WinForm program, but to date I have simply released an all-new compile. People have to un-install the old version and install the new version.
EDIT: I'm using an auto-generated InstalWizard. It preserves my file strucutre and places the [PrimaryProgramOutput] in a particular directory. I forget what this is called.
I bet there's a way to get around this, but I don't know what it's called. As you may guess, searches for "updates" "new version" "install" and the other obvious things I've tried have generated an impressive number of irrelevant results. >_<
I suspect this process has a particular name, which should point me in the right direction, but if it doesn't please link to a tutorial or something.

I see from the tags you are using C#. Visual Studio can create Setup projects for these kind of tasks. The setup projects als contain a property RemovePreviousVersion, which will remove a previous version if the versioning of your setup is correct and the GUID of the application stays the same.
See this link for more information:
http://www.simple-talk.com/dotnet/visual-studio/updates-to-setup-projects/

ClickOnce deployment is a great solution most of the time...
You can deploy to the web and when ever your users start the application it will check for updates and automatically update the application if there is a new version available.
It can also be configured not to update automatically but only to notify the user that there is a new version available and allow the user to control the update process.