• 0

Why don't I see anyone using app.config to store settings?


Question

I've been searching by articles related to XML + application settings and I've found quite a few, this means that people like to save things this way. I mean, have their own XML file and save their settings there instead of using the built-in AppSettingsReader class.

Why is that?

Is there a problem in using the app.config/user.config files to store application settings?

Basically, what I want to know is the problems and/or cons that you can list by using app.config/user.config to store application settings. I don't really care about the pros right now, just the cons of using this method.

Is there any?

Link to comment
Share on other sites

15 answers to this question

Recommended Posts

  • 0

I've never used app.config, I've always used my own xml files. I know my method I can use any format I want (within xml guidelines). I can setup my own set of tags and set up my own project/window settings tree. App.config (I could be wrong) goes off of a set of strings, (<add key="variable1" value="some value here" />) which can limit you if that's the case b/c you can have multiple sets of descendants. For example:

<Project>

<Name>Default Prj</Name>

<Files>

<File path="test.xml" version="1.0" />

<File ... />

</Files>

</Project>

If I'm wrong feel free to correct me.

Link to comment
Share on other sites

  • 0

If you really know what you're doing you can do anything with app.config or web.config, you just have to implement your own configuration sections and then register them in the config file to represent any kind of data you want. Most people don't use it because they don't want to "waste" time exploring the potential already in the Framework.

Link to comment
Share on other sites

  • 0
If you really know what you're doing you can do anything with app.config or web.config, you just have to implement your own configuration sections and then register them in the config file to represent any kind of data you want. Most people don't use it because they don't want to "waste" time exploring the potential already in the Framework.

+1

I try to leverage the app.config as much as possible, but I think a lot of people have the "if it isn't written here..." syndrome, so they write their own solutions, which, imo, is a waste of time. I'd rather use a well tested, well documented system than write my own.

Link to comment
Share on other sites

  • 0

I was completely wrong lol, so just ignore what I said. I just like creating my own xml config files, that's just how I've always done it. Nothing wrong with doing it in app.config it seems either though.

Link to comment
Share on other sites

  • 0
If you really know what you're doing you can do anything with app.config or web.config, you just have to implement your own configuration sections and then register them in the config file to represent any kind of data you want. Most people don't use it because they don't want to "waste" time exploring the potential already in the Framework.

I appreciate your input and I don't want to sound harsh but that's not what I asked... I asked for problems in this method and apparently there is some as someone replied me on another forum:

As for App.config, one con is that it is only loaded at startup. You can write to it, but those values by default will only be accessible on startup. That goes for the configuration/appSettings section anyway. I had to write my own little method to refresh the data after dropped like 50 settings into the App.Config/configuration/appSettings and the I couldn't get the canned ConfigurationSettings.Refresh method (or whatever it is called) to work. I'm reasonably certain it only reads it into memory, so I used XmlDocument, actually I saw a reasonable article on codeproject.com after several hours of searching for something useful.

I'm not gonna say it's 100% true or false because I don't know anything about the app.config/user.config file, but that's what someone said and it shows a problem to me.

Also, there are a few other things that I don't like with this method... I can't choose my own path for the user.config file, as far as I know...

Anyway, could you explain the following a little better and/or provide a small example:

"(...)you just have to implement your own configuration sections and then register them in the config file to represent any kind of data you want(...)"

Link to comment
Share on other sites

  • 0

As with anything in software, there are compromises. If you really need a dynamic config file, then by all means, write your own or try to override behavior of some existing framework. It's been extremely rare in my experience to need such a thing, and typically, it's usually only when I'm creating a system. The config is not for user preferences, IMO. It is for configuration of the application, i.e. data the app needs in order to operate correctly, and, for me, has rarely been user definable.

Anyhow, writing your own sections is actually quite simple in 2.0+. It is a little more work in 1.1, but still quite simple.

http://msdn.microsoft.com/en-us/library/2tw134k3(VS.80).aspx

As far as the read/write config not refreshing properly, I couldn't say one way or the other. I'm stuck in 1.1 land for the moment.

Link to comment
Share on other sites

  • 0
I appreciate your input and I don't want to sound harsh but that's not what I asked... I asked for problems in this method and apparently there is some as someone replied me on another forum:

I'm not gonna say it's 100% true or false because I don't know anything about the app.config/user.config file, but that's what someone said and it shows a problem to me.

Also, there are a few other things that I don't like with this method... I can't choose my own path for the user.config file, as far as I know...

Anyway, could you explain the following a little better and/or provide a small example:

"(...)you just have to implement your own configuration sections and then register them in the config file to represent any kind of data you want(...)"

There is a good article on custom configuration sections that will explain what I believe Cool4 was inferring about extending the configuration beyond that standard key-value types.

http://devlicio.us/blogs/derik_whittaker/a...n-sections.aspx

This article shows how to setup the handler, section, and simple objects to represent the data. Once you become familiar with configuration object representation and standard serialization methods, you should be able to do just about anything you need with the configuration file. As for the user settings sections, there are specific articles on using the VS2005 (or VS2008) designer to work with those types, persist any updates, and use them in your application. If you have problems finding one, let me know and I'll provide a link or two.

Hope this helps.

Link to comment
Share on other sites

  • 0
The config is not for user preferences, IMO. It is for configuration of the application(...)

What are you saying exactly? Can you be a little more specific? Cause everyone seems to recommend me to use the app.config/user.config for user settings, I mean, ym application settings like "startup with windows", "minimize at startup", that's stuff like that I'm talking about...

You are saying that the user.config/app.config is not for these kind of things? I understand that's only your opinion but would you mind explain why you think the config (as you call it) is not for user preferences?

I'm not agreeing/disagreeing with you as I never used the user.config/app.config file so I can't say much about, just curious about the reasons you have to say that :)

@Glen

That's a pretty big article.. I'll take a look at it when I get the time, I'm kinda sleepy right now, Rock In Rio Lisbon was hard on me :p

Link to comment
Share on other sites

  • 0
What are you saying exactly? Can you be a little more specific? Cause everyone seems to recommend me to use the app.config/user.config for user settings, I mean, ym application settings like "startup with windows", "minimize at startup", that's stuff like that I'm talking about...

You are saying that the user.config/app.config is not for these kind of things? I understand that's only your opinion but would you mind explain why you think the config (as you call it) is not for user preferences?

I'm not agreeing/disagreeing with you as I never used the user.config/app.config file so I can't say much about, just curious about the reasons you have to say that :)

@Glen

That's a pretty big article.. I'll take a look at it when I get the time, I'm kinda sleepy right now, Rock In Rio Lisbon was hard on me :p

It's just a personal preference for me to not store user prefs in a config. I typically, depending on application type, will store user prefs in a database, in a serialized class written to user local storage, or in a HKCU key. I'm of the mind to not pollute the config, especially in a multi-user environment. A couple of my reasons are that XML can get huge in memory, and what was a simple config file at one point, can easily deteriorate into a nightmare if the developer isn't judicious. If I know something will only ever be used in a single user environment, then I don't think I'd have a problem storing prefs in a config. That's my rationale. :)

MY choices are based solely on what I am tasked to do. Are they more correct? Nah. That's one of the beauties of software - an infinite amount of ways to skin a cat, though there are some ways better than others.

Link to comment
Share on other sites

  • 0

I am using app.settings specifically just for user settings, for example saving the last location and size of the main form. I know that if I change a setting at runtime the change goes into user.settings under AppData folder.

When I compile in VS2008, app.settings turns into myexe.exe.settings in the \bin\Release directory.

However I have noticed that I do not need to distribute myexe.exe.settings in the product installer.

Can someone tell me definitively if the default user settings are compiled in to the exe? If this is true then why is myexe.exe.settings generated?

I ran a test in VS2008 - I created a simple form with a textbox, and on Load, the textbox retrieves a user setting from Properties.Settings.Default.MySetting.

It compiled and ran successfully. I then deleted myexe.exe.settings from \bin\Release and ran the program. The setting was still retrieved successfully. Now I had not changed any of the settings so there wasn't a user.settings present in AppData. So it must be compiled in to the main exe, right?

Thanks,

Dave

Link to comment
Share on other sites

  • 0

app.config is normally used for semi-permanent settings like database connection strings.

@Squid Dog: The default settings are stored in the compiled application. It is supposed to create a settings store when you change something if the file doesn't already exist.

Link to comment
Share on other sites

  • 0

XML is really flexible that is why I use it. I can create formats within it for anything I need/want and very fast too, it also makes it easy for other programmers to write applications that work with my Programs using the XML setting files and if your program supports Add-ons other developers can use your own XML formats to control their Add-ons or even create an entire Add-on in XML if you include such broad support for dynamic files beyond just storing settings.

I know a lot of programs use ini files and I do use those myself sometimes but when I'm being serious about what I'm writing its XML all the way for me.

Link to comment
Share on other sites

This topic is now closed to further replies.