App.Config vs Custom XML file
Asked Answered
E

5

7

I have read a lot of statements like "you shouldn't clog your app.config file with custom settings". However, I was under the impression that this was exactly the purpose of the file?

Is it just indeed a preference thing? Or are there any real benefits (other than separation of settings) by using a custom XML file, as apposed to the app.config file? If you need to explicitly separate settings would it better to use a custom ConfigurationSection rather than opting for a custom XML file?

I would like to here other peoples thoughts on this.

Elisabeth answered 14/10, 2009 at 12:18 Comment(0)
T
5

Some people tend to go a bit overboard on custom config section handlers, in my humble opinion.

I tend to use them only when I need something that is very structed; and that is used/written by 3rd parties (i.e. I want to do some extravagent validation on it).

I think you can quite happily use app.config/web.config for all relevant settings, and use separate XML files when it is very clear that is a separate component of the app.

Tackle answered 14/10, 2009 at 12:26 Comment(0)
S
5

Have a look at the Application Settings Architecture, the app.config is for Configration regarding the Application, thats quite a general term though.. So I would suggest you look into the Application Settings Files.

I would not store settings like "load database on startup or not" in the app.config. I would rather use an Alternative Storage like Application Settings for this, don't confuse Application Configuration with Settings, even though you might want to do that, Don't. app.config is supposed to have configration regarding lower level things like Database connection, Membership Provider or any other Application Critic information.

Sturgill answered 14/10, 2009 at 12:23 Comment(0)
T
5

Some people tend to go a bit overboard on custom config section handlers, in my humble opinion.

I tend to use them only when I need something that is very structed; and that is used/written by 3rd parties (i.e. I want to do some extravagent validation on it).

I think you can quite happily use app.config/web.config for all relevant settings, and use separate XML files when it is very clear that is a separate component of the app.

Tackle answered 14/10, 2009 at 12:26 Comment(0)
H
2

Most settings tend to fall into one of three camps:

  1. Technical settings that affect the internal behaviour of the code, e.g. database connection string, data file path, logging switches, error handling switches, etc.
  2. Business settings that affect the business logic of the product, e.g. "are users allowed to access the CRM Module?"
  3. User-specific profile values, e.g. "is this user allowed to access the CRM Module?".

The natural place for type 1 is in app.config or web.config, and the natural place for types 2 and 3 is in the database.

Hearts answered 14/10, 2009 at 12:34 Comment(0)
W
1

App.Config are good for configuration that are application specific : path to database is a good example. The rest should be out of it.

One thing you might want to do is to create user-specific files, you can then use custom xml that will be saved into an IsolatedStore.

Whacky answered 14/10, 2009 at 12:22 Comment(1)
I suppose the issue is what is considered "application specific". As I assume all settings that you need for your application are application specific...Elisabeth
C
1

In my opinion I consider app.config to be good for deployment-time settings such as the location of the database, or an IP address or location of critical data file, etc. User settings like font, color, behavior preferences should go in a different file which you can easily create and save with Xml serialization.

Cleave answered 14/10, 2009 at 12:25 Comment(2)
Would you consider the same solution for things like UI messages etc?Elisabeth
If UI messages are something the user directly configures then sure. But if you are thinking about UI messages in terms of language translation then you should look into satellite assemblies and .NET's support for localization.Cleave

© 2022 - 2024 — McMap. All rights reserved.