views:

169

answers:

4

Settings.settings generates Settings.Designer.cs which presumably generates app.config which then is copied to output directory as Foo.exe.config. When I distribute the application without the config file, nothing bad seems to happen. So, what is that file for?

+1  A: 

Application configuration files contain settings specific to an application. This file contains configuration settings that the common language runtime reads (such as assembly binding policy, remoting objects, and so on), and settings that the application can read.

astander
Yes, I've read the manual, but what is that file *really* for?
CannibalSmith
@CannibalSmith: Exactly that - configuration settings. I don't understand why you're confused.
Jon Skeet
When I delete it, configuration settings don't go missing. Configuration settings are stored somewhere in Users/Foo/AppData/BlahBlah.
CannibalSmith
This file is a per application config file, where you can store items such as multiple data source connections(connectionStrings), multiple key values pairs (appSettings), remoting configurations (system.runtime.remoting, you have used remoting before?), channels, etc...
astander
@CannibalSmith: Only user settings are stored there. Application-wide settings are stored in app.config. If the file doesn't exist, the defaults are used.
Jon Skeet
A: 

You can store your configuration in that file.

The .Net framework will automatically load a config file with the exe-name.config.

If you dont use any configurations in your application, then nothing bad will happen...

Heiko Hatzfeld
+3  A: 

If you don't have the config file, it uses the default values from the designer. However, the config file allows users/administrators to easily change settings - such as the server you talk to, themes, etc. If you don't have the file, where would you expect those settings to be stored?

You can have per-user settings as well as per-application settings, which are stored in different locations.

Jon Skeet
Oh, so the config file is for applications that don't have an interface to configure their own settings?
CannibalSmith
where do you intend to store these settings then, in the db?
astander
@CannibalSmith: If you want to create your own complete config system, including storage etc, then you can ignore app.config. Why reinvent the wheel though? Note that the config system in .NET *is* extensible (so you can theoretically store the settings in the registry, a database etc) but it's somewhat confusing and poorly documented in that respect.
Jon Skeet
I store the settings in Settings.settings and Properties.Settings.Default. Whare do they *really* go, I don't know, but they certainly don't go to app.config, because, like I said, if I delete that file, the settings don't vanish.
CannibalSmith
But I think I've got it. Foo.exe.settings override the *default* settings of the application. If you edit it *before the application is run for the first time* then the changes will be reflected in the application. That would allow an installer script to tailor the default settings to the system I assume.
CannibalSmith
@CannibalSmith: For application-scope settings, it doesn't matter *when* you edit it. I haven't used user-scope settings much - from what you're saying, it sounds like they get copied on first run.
Jon Skeet
A: 

The config file is optional, if it does not exist environments such as ASP.NET will fall back to the machine.config file stored in the .NET system directories to get machine wide defaults.

If you actually add code to your app to retrieve settings from the config file (say using the ConfigurationManager class) and it does not exist, you will receive null values.

That is why it is important to check for this siutation and have your application make it's own decision on how/if to continue.

Ash