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?
Asked
Active
Viewed 3.7k times
33
CannibalSmith
- 4,742
- 10
- 44
- 52
4 Answers
40
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
- 1,421,763
- 867
- 9,128
- 9,194
-
1Oh, so the config file is for applications that don't have an interface to configure their own settings? – CannibalSmith Sep 16 '09 at 08:54
-
where do you intend to store these settings then, in the db? – Adriaan Stander Sep 16 '09 at 09:03
-
2@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 Sep 16 '09 at 09:09
-
2I 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 Sep 16 '09 at 09:15
-
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 Sep 16 '09 at 09:19
-
1@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 Sep 16 '09 at 09:39
-
Suppose I manually change some
in app.config, save it and then close it. Now when I go to my bin folder and launch the .exe file from here, why doesn't it reflect the applied changes? – Ekta Sep 09 '15 at 14:45 -
1@Ekta: My guess is that you didn't rebuild. – Jon Skeet Sep 09 '15 at 15:07
-
I've found that if you deploy the app.config and then change settings on the server, the changed settings are ignored at runtime, so I don't get why you would need to deploy it. That's why tools exist like SlowCheetah so you can do transforms at build time, right? But it's unfortunate that SlowCheetah only seems to work on connectionstrings and not application settings. This is unfortunate because you can't store settings there that can be used to cause different behaviors based on Debug, Test, or Production environments. It's almost like you have to go back to ini files for those purposes – Del Lee Jul 26 '17 at 17:26
-
@DelLee: You'd have to give more specific details for us to be able to help, to be honest... And those should be in a different question. Changing foo.exe.config in the deployed environment should work fine. – Jon Skeet Jul 26 '17 at 17:44
-
Thanks @JonSkeet, I'll look at that. Seems counter-intuitive to have to know about and then change a foo.exe.config when the google searches I've done researching app.config do not reveal anything about it and most everything seems to imply that changing the app.config is all that is necessary, and then confusingly there is the SlowCheetah tool which exists for the same reason. Why not just keep it simple and not embed what's in the app.config at build time and let it be readable where ever it sits at run time? These seemingly esoteric things are frustrating. – Del Lee Jul 26 '17 at 20:41
-
@DelLee: I don't believe that what's in app.config *is* "embedded" at all. It's just converted into foo.exe.config and copied alongside the executable. I've never used SlowCheetah, so can't comment on how it's related. But it's not like there's ever only been one way of doing configuration... – Jon Skeet Jul 26 '17 at 20:42
8
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.
Adriaan Stander
- 162,879
- 31
- 289
- 284
-
When I delete it, configuration settings don't go missing. Configuration settings are stored somewhere in Users/Foo/AppData/BlahBlah. – CannibalSmith Sep 16 '09 at 08:51
-
2This 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... – Adriaan Stander Sep 16 '09 at 08:55
-
1@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 Sep 16 '09 at 09:10
4
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
- 60,973
- 31
- 151
- 169
1
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,197
- 18
- 15