views:

88

answers:

6

I want to store settings for my C# application, such that default setttings can be easily shipped with my binaries and the end-user can change them using a simple text editor(or in some other simple way).
I seem to face several alternatives : a .config file, .settings file or a .resx file. What are the pros and cons of these?

Edit1: End-users are computer professionals mainly, so editing these files should not be much of a problem.

Edit2: The settings are something like connection strings, and some other parameters (mostly one-time stuff). Building some kind of GUI/API for changing them is not really an option. Also my application will not edit any of these values, so persistence through code is not required.

A: 

If the end user is really going to be editing them, I'm not sure I would want them editing my app.config file.

You have another couple alternatives that you haven't included. You could use an old-school .INI file that is simpler for an end user to understand. You could also use the registry. I would recommend the INI file, unless your users are very savvy, in which case use the .config file.

Fosco
+1  A: 

I think you can have two ways of doing this.

  • For regular users, you can make a custom GUI that will make it simple for them to use.
  • For advanced users, they can edit the configurations using a text editor if it's stored in a text file (ini file, config file, etc..) or you can make an API.
John
+1  A: 

The .settings file is typically used for user-specific preferences and configuration information (whereas the .config file is used for global settings for the application or anything that modifies the .Net runtime. Simply putting parameters in a .config file can alter the behavior of your application even without you writing a single line of code for it).

Check out the Settings article on MSDN for more: http://msdn.microsoft.com/en-us/library/aa730869(VS.80).aspx

rakuo15
Can you explain how .config file can change the behaviour of my application?
apoorv020
There are several ways, and most .Net components have their own sections that they rely on in the _.config_ file, but some examples I can think up of off the top of my head: For WCF, you can modify connection timeouts, security and encryption level, etc, right in the _.config_ file. You can also replace GAC DLLs with local DLLs, or specify version and bitness specifics in the _.config_ file that would override what the runtime will load.
rakuo15
Hans says that you would probably need admin access on the machine to change the .ex.config file, which is exactly what I require and should take care of most malicious users. But point taken, it can be a very dangerous tool to provide to an average user.
apoorv020
A: 

The answer depends on the deployment method. For instance, if you are using ClickOnce and offer updates, you might encouter problems using Application Settings.

I believe the best way to go is to create a GUI, something that is most certainly suitable for novice users. Given that you already excluded that option, use John's suggestion (ini files).

Anax
+3  A: 

Yes, Project + Properties, Settings tab was designed to do this. Add your settings here, change the Scope to Application. That generates a app.exe.config file in your build direcctory, deploy it along with your EXE. Use Properties.Settings.Default.SettingName in your code to obtain the setting value. Your user will normally need admin privileges to edit the .exe.config file on the target machine to change the setting value.

The small print: settings do not work well for DLL assemblies, you have to merge the .config files by hand. When using the debugger, settings are retrieved from the app.vshost.exe.config file.

The .settings file is a helper file used by the IDE, ignore it. .Resx files store resources, they get compiled and embedded in a binary form in an assembly. They are not editable by the user.

Hans Passant
+1  A: 

Since the file will be modified by the users, I think using app.config is not a good idea. What if they break the file structure? Or set an invalid value? Probably your application will crash directly.

One of the solutions would be to use a custom XML file. You will then validate it when your application starts. XSD will probably be the more elegant way to do it, but you can also parse it directly and validate it in code. If the file is invalid, instead of crashing, you will try to solve the problem, and if impossible, display a pretty error to the user, explaining that there is an error in XML at line n, position n, which is [error description here].

MainMa