We Keep Coding

How to manage different settings for each customer?

We have 1 settings file with the customer settings for each costumer, but the problem is that we have to change lots of settings values when releasing a new version for each costumer, as we develop using the test settings. So, its a totally mess.
Whats the best solution for this?
Having one settings file and app.config for each costumer?
Saving the configurations into the database?(we would still have the connection string settings)
Each costumer cant see the settings from the others..

We use a Configuration Transformation for this and have multiple Build (Release) configs like
Release-Internal
Release-CustomerA
Release-CustomerB
You can have one "base" config file and just replace the values you need for the specific configuration.
Your file structure would look like this afterwards
app.config
app.Release-Internal.config
app.Release-CustomerA.config
app.Release-CustomerB.config
We usually use this for the connection strings and some specific view settings.
Visual Studio only has nativ support for ASP.NET projects (for whatever reason), but there are multiple Plugins to enable this for other .NET projects.
I can recommend Configuration Transform (I like this one better) or SlowCheetah.

Different application settings per executable

I'm creating an application and I make use of Properties.Settings to store the settings.
However, let's say my application is on the desktop of the user and is called Program.exe, now, when the user copies this executable and places it somewhere else or even renames it, all settings are gone.
Why is C# doing this? Is there any way this can be turned off while pertaining the user scope? I don't wish to use the application scope since multiple users can be sharing the same computer.

The settings are likely stored in {appname}.exe.config which apparently is not being copied/renamed with the executable. Either copy the executable with the file, hard-code them in the application, or find another mechanism to get/set app settings (like the registry).
The application will look for these settings in a file titled {appname}.exe.config. If the executable is renamed (without renaming the .config file) or copied to another location without copying the .config file along with it, the application won't know where to look for their settings so they will be blank (unless you set a default value in the app).
You can "hard-code" default settings by putting a value in the Settings.settings "file" in Visual studio (which effectively adds the default value as an attribute to the setting).
Another option would be to hard-code the values directly in the source code. I'm NOT recommending this approach as it hinders the ability to change that value, but if you want to be able to deploy the app by just copying the EXE (and nothing else) then it is an option.

See http://msdn.microsoft.com/en-us/library/aa730869(v=vs.80).aspx for details.
The settings (and their location) when using Properties.Settings is determined by the Scope setting of the particular setting.
Settings that are Application scoped are in the app.config file (renamed at compile time to .exe.config - these settings are read only at run time), and settings that are User scoped are saved in a user.config that is tied to the user's profile on the machine (these settings are read/write at run time). By properly scoping your settings you should be able to avoid this type of problem.

Settings are stored in the user profile (under C:\Users[UserName]\AppData\Local), these settings are under folders that have the application name and also have an identifier of the location of the exe file they refer to, for example: MyApp.exe_Url_hpvvra0rj4y03ebpz3cfmzsrcpczat11, refers to the executable under Program Files, if i move or copy the exe and run it, it will create another folder with another URL (MyApp.exe_Url_vqzsq0spwewydv3wrnebtqji24nwuboe, for example), i haven't find a way to avoid this but a good workaround is to copy the settings from another config file, just note that this method is not foolproof as you have to choose the right file to copy the setting to and if you expect your exe to be copied or moved constantly this will be a hard task.
Another workaround is to simply create your custom settings class and put the file anywhere your application can find it and don't realy on the built in settings on .NET.

Migrate away from settings file

I use a settings file in my project in addition to a configuration file, and I wish to move away from using the settings file in preference to the configuration file.
The settings file is the default .net application setting mechanism (ApplicationSettingsBase), and my configuration file is a custom class that I serialize and deserialize manually.
I have successfully in the past applied the NeedUpgrade/Upgrade() logic to keep settings from previous versions, but somehow it seems settings are lost non-the-less.
The difference with this project in regards to earlier projects, is that it is deployed using Click-Once.
To work around the problem, I wish to move away from the settings file all together and rather use my configuration file which is stored in a static folder (Environment.SpecialFolder.LocalApplicationData), but I do not know how I best would proceed in managing this migration/change.
Any advice is appreciated.

where property.setting value stored in c# windows application

I thought it should be a config file, but cannot find it.
thanks

The whole config file location can be a bit slippery. Depending on whether or not its a "user" setting or an "application" setting, it will go into a different file. Some settings can even come from your "machine" config (Like in the case of ASP.NET). Instead of guessing where everything is, I find it much more useful to ask .NET where it is looking for these files. Roughly:
//Machine Configuration Path
string path1 = ConfigurationManager.OpenMachineConfiguration().FilePath;
//Application Configuration Path
string path2 = ConfigurationManager.OpenExeConfiguration(
ConfigurationUserLevel.None).FilePath;
//User Configuration Path
string path3 = ConfigurationManager.OpenExeConfiguration(
ConfigurationUserLevel.PerUserRoamingAndLocal).FilePath;
App.Config
This is what gets added to your project. The build process will name it [myproject].exe.config. This holds the (mostly) read only application settings and the application-level defaults for user-specific settings. Application level settings are difficult to programmatically change their values. Application level setting properties will only have "get" defined. The intention is: if your setting is for all users of the application, then a manual edit (or the installer) should set them. If it changes per user, then make it a per-user setting.
Binary Default Settings
Your application will run without its [myproject].exe.config file. To do this, the binary has its own version of the file "stored". This is useful in some ways, but can be confusing. If you have a .config file in the wrong place or with the wrong name, .NET reverts to the "binary defaults". It can cause the appearance of not being able to affect the settings by changing the config file. Use the method above to know where the .config REALLY goes, or face the wrath of the binary default settings.
User.Config
This is generated the first time you "save" your Default.Settings object with a "per-user" setting. This file is saved in the user's profile path in a location based on your project's name, version, operating system, and some other dark .NET magics. The properties for these settings are readable/writeable. They are designed to be easily set and then saved with a single call.
Pulling it Together
So where do my settings go? The answer is that potentially many files are joined together to get the "Active set" of settings. App.config and user.config settings are the basic blocks, but there are machine.config settings, and then there are dependency assembly settings that can further complicate things...but thats another topic entirely.
The real truth of config files is spread across a lot of ugly cases and details. However, with a little knowledge about how they are joined together, it is a fairly useful system. Especially if you realize you can databind to these settings ;)

If you're talking about .Net settings, then they will normally be in a .config (xml) file in the same directory as the application. When you save them, however, a local copy gets saved in to a user writable folder (typically C:\Users\username\AppData\Local under Vista). Under XP, look in the Documents and Settings folder.
The .Net application uses this file in preference to the 'default' one in the application directory.
Hope this helps.

On Windows XP, it's stored in a file called user.config in a subfolder of:
C:\Documents and Settings\username\Local Settings\Application Data
http://dotnetproject.blogspot.com/2006/08/where-is-userconfig-file-located-in.html

Are you referring to the .settings file in your application? When you add values to that file, an app.config file gets created for you. You should be seeing it in your solution explorer.

Manage multiple app config files during development

I'm building an application that is used by several different customers. Each customer has a fair amount of custom business logic, which I have cleverly refactored out into an assembly that gets loaded at runtime. The name of that assembly, along with a number of other customer-specific settings, are stored in the application's configuration file.
Right now, here's what I have to do in order to debug the application for customer foo:
Go to the filesystem in my project directory and delete app.config
Copy app.config.foo to app.config.foo - Copy.
Rename app.config.foo - Copy as app.config.
Tell Windows that yes, I want to change the file's extension.
Switch back to Visual Studio.
Open the Settings.settings item in my project.
Click "Yes" 13 or 14 times as VS asks me if I want to use the new settings that have been changed in app.config.
Close Settings.settings.
Okay! Now I'm ready to debug!
It seems to me that the rigamarole of opening Settings.settings is, or ought to be, unnecessary: I don't need the default values in Settings.cs to be regenerated, because I don't use them. But it's the only way I know of to make VS aware of the fact that the app.config file has changed, so that the build will copy it to the output directory.
There's got to be an easier way of doing this. What is it?

You can also let Visual Studio automate Robert`s approach by:
Define a Build Configuration for each client
In the post build event, simply xcopy app.config.xxx to your bin folder. Where XXX is the name of a Build Config accessible in VS. Something like: xcopy app.config.$(ConfigurationName) $(OutDir)/app.config
VS will drop a distinct build for your clients in separate folders, aolong with the proper config file.
bin/Client1/
bin/Client2/

You can refer this post for some good practices : Managing Multiple Configuration File Environments with Pre-Build Events

Thinking about the mess of managing multiple configuration files I made this tool: http://envride.codeplex.com/
Its purpose its exactly to make it easier to manage multiple configuration files in an automated way. I would be very pleased if you would take a look at it.

A couple of people suggested using multiple VS configurations, which I think would have worked, except that it would require me to rebuild the solution every time I switched between configurations.
What I did instead seemed a little stupid while I was doing it, but I've been using it for nearly a year now and it works extremely smoothly. In my project directly, I create a separate app.config.XXX file for each customer. The actual app.config file is used solely to generate Settings.cs - it has all of the correct setting names and their default values. It doesn't get copied to the build directories, ever.
Then I wrote a little program that lets me select a customer, and that simply goes through the directories for each project and, if I selected customer XXX, copies app.config.XXX to bin\debug\myprogram.exe.config and bin\release\myprogram.exe.config. As long as this program knows where the root of the solution is (I have to be a little careful whenever I branch the code), it works like a charm.

This thread is too old to represent current tools in VS.
You can use an addon that acts similar to web.debug.config but for app.config.
https://marketplace.visualstudio.com/items?itemName=GolanAvraham.ConfigurationTransform
And for the same app.config transformations without addon.
https://www.linkedin.com/pulse/multi-appconfig-visual-studio-2017-benjamin-davis/

You may opt to define multiple Visual Studio solution configurations, one for each customer, and have customised MSBuild targets for your Windows app project.
I have documented the steps of how I handled this here. Multiple app.config files for deploying to different environments

After a little digging and work around I got my Test project working with multiple configurations,
In the Configuration Manager, create the configurations you need
Copy paste your app.config and add the name of the configuration, in my case is AHI, FIV, MGC, so my config files look like: App.AHI.config, App.MGC.config, App.FIV.Config. You can name it how ever you wanted, but keep the same convention
Add a Post-Build event. In my case it would look like: xcopy $(ProjectDir)app.$(ConfigurationName).config $(TargetDir)$(TargetName).dll.config /y
here is my post, so you can read it with more details
Running a Test Project with Multiple Configurations