views:

128

answers:

10

Recently, I discovered that the "Web.Config" file contains an <appSettings> section which seemed good for storing one's Application Settings. Heck, it even has a programmatic way to access the file thru a standard System library. So being all clever, I wrote an Interface to access it and then a Concrete implementation of the interface, shown here:

public interface IAppSettings
{
    IEnumerable<string> GetValues(string componentName, string settingName);
    IEnumerable<KeyValuePair<string, string>> GetValuePairs(string componentName, string settingName);
    void SetValues(string componentName, string settingName, IEnumerable<string> valueList, bool append);
    void SetValuePairs(string componentName, string settingName, IEnumerable<KeyValuePair<string, string>> pairList, bool append);
}

Then I came to discover that saving settings back to "web.config" while the application is running causes the entire application to re-start. This seems completely unreasonable to me because if I'm writing back to web.config a lot and the application is restarting each time, then things like HttpRuntime.Cache get completely emptied effectively making my Cache useless because it's constantly emptying and repopulating.

So I'm wondering: Where should I store my Application Settings?

Is there a good solution out there for this so that I don't have to roll my own?

EDIT:

Okay, thanks to everyone who suggested using a DB and a potential table schema. I think I'm going to go with the following schema:

settings:
    index NUMBER NOT NULL AUTO_INCREMENT   <== Primary Key
    component NVARCHAR(255) NOT NULL
    setting NVARCHAR(255) NOT NULL
    key   NVARCHAR(255)
    value NVARCHAR(255) NOT NULL

Though I don't think I'll make the "setting" the P-Key, but use an Auto-Incr Index instead. This way if I have an application that needs to mail something to multiple managers, I can store many:

index     component       setting        value
1         RequestModule   ManagerEmail   manager1@someplace
2         RequestModule   ManagerEmail   manager2@someplace

And then I can use:

IEnumerable<string> GetValues(string componentName, string settingName);

And it will return a list of email addresses, rather than just a single value.

Does this make sense?

+3  A: 

It is meant for application settings, but not settings that are meant to be dynamically changed during runtime. Rather, it is for settings that change only occasionally, and where you would expect (and even desire) an app restart when they change.

For more ephemeral settings, you may want to just use a simple database system - even a flat file/XML in the App_Data dir can work, if your app doesn't use a database otherwise.

Andrew Barber
+6  A: 

web.config is generally used for read-only settings, ie. the settings set during deployment of the application by the system administrator.

If you want to read and write the settings, the most obvious way is to use the database. By the way, this has an advantage: an application can be hosted on several servers and will still read and write the settings correctly,

You can also implement your custom storage for the settings, but it will be probably more difficult to implement and not much faster.


To answer your second question, the structure of your database depends on the type of settings you want to store.

If you need to store heterogeneous unique entries like this:

  • Mail address of an administrator,
  • Maximum number of entries to display on home page of the website,
  • Text to display on "About us" page,
  • Boolean value indicating whether public comments are enabled or not,

then you have to use varchars or other more or less friendly types as keys to identify the entries (rather than to refer to them by their index).

On the other hand, if your purpose is to store the mail addresses of several managers, you should create a Manager table containing their mail addresses, names, datetime of their last connection, etc.

You really shouldn't mix both. In theory, you can refer to the entry in settings by component/setting pair. In practice, it makes things harder and creates a bunch of problems:

  • What if, further, you will need, for every manager, to store a boolean value indicating whether she/he wants to receive alerts from you? With your current structure, this will be impossible.
  • Since the same setting can have multiple values, how do you intend to handle the settings which must be unique? For example, there must be only a single value of text to display on "About us" page. What if there are two values stored in database?
MainMa
Interesting, I hadn't considered an application possibly running on multiple servers, but it makes sense. In my case, it likely will never happen because it's for an internal company project, but this is good to keep in mind.
Pretzel
+3  A: 

Yes.Changing the web.config will reset the application.I usually maintain a settings table to store key-value pairs for the settings and access it from there.

SETTINGS

SETTING_NAME   VARCHAR(100)PRIMARY KEY
SETTING_VALUE  VARCHAR(100)

Then write a class which can Insert,Delete,Update values to this table.

Ex Data for the SETTINGS table

    SETTING_NAME         SETTING_VALUE

    AdminEmail            [email protected]
    ErrorTrackingEmail    [email protected]
Shyju
`name` should be primary key. Separate columns makes no sense
abatishchev
I missed that.Thanks abatishchev for noticing it,Edited answer
Shyju
A: 

You can save stuff in the registry

http://www.csharphelp.com/2007/01/registry-ins-and-outs-using-c/

or

http://www.geekpedia.com/tutorial48_Using-the-Windows-Registry.html

Robert
Please don't do this. You should never need to make changes to the registry from a web application and to be honest i'd be surprised if this was possible from an asp.net app without impersonation.
Andy Rose
There is no rule that states things cannot be saved in the registery. I write server web apps that need to save things like application settings in the registry.
Robert
Hadn't even crossed my mind as I had already eliminated this as a possibility, but thanks for the warning anyway!
Pretzel
well, there's a new interview question. "would you consider it good practice to write to the registry from a web app? you would? ok, we're done here."
lincolnk
Thats, funny that was actually an interview question I got :)
Robert
There's so much wrong with doing this. These application settings are meant to be modifiable otherwise they'd be hard-coded, should users remotely login to the server and fire up regedit? It makes migrating your web application to another server much harder. Just no, don't do it.
Fishcake
Ok. Truthfully I really understand where you guys are coming from. But try to understand not all Web Apps are the same. My application manipulates Active Directory, IIS, File management. It is an intranet based app that will be installed using an installer. My suggestion may not be the best or a good one, but just a suggestion.
Robert
+1  A: 

Create a key-valued table like this:

settings:
name NVARCHAR(255) PRIMARY KEY
value NVARCHAR(255) NOT NULL
abatishchev
+2  A: 

Storing settings in web.config is useful because it makes it easy to have different settings in different environments. However, as you say, this is no use if you are likely to want to change the settings in a live environment.

A simple database table is the most useful way to do this if you need to change the values.

eg.

create table Settings
(Name varchar(50) primary key,
Value varchar(50))

If you're using SQL Server, you can set to the Value column to be sql_variant which will allow you to store a variety of datatypes.

Paul Spangle
+1 for `sql_variant`. `nvarchar(max)` is not a good idea when storing data of any type (not to mention `varchar(100)`).
MainMa
+1  A: 

First of all, it's not unreasonable at all when you consider what information is supposed to be stored in the web.config file. When you change things like assembly information, connection strings, etc., your application needs to stop and reload the values to run with those settings.

If you're storing application wide settings, then you can create a Settings table in your database or even use a separate text file to store the settings.

If you're talking about storing per-user settings, you shoul check out ASP.NET Profile Properties.

Justin Niessner
By "unreasonable", I meant the constant "restarting" of the application was a side-effect that would have performance issues that I wouldn't be able to tolerate. (not that the reason behind it restarting was unreasonable...) -- Thanks for pointing out the ASP.NET Profile properties. It's not exactly what I'm looking for, but I think it will help me out with another problem I'm having... :-)
Pretzel
A: 

Application-wide settings should certainly be stored in this section of the web.config file, as it prevents hard-coding values which may change over time. There's no need to read them out using your own code, as there's a built-in method: use the System.Configuration.ConfigurationManager.AppSettings array to retrieve them (you'll need to add a reference to the System.Configuration assembly in your project). You can edit AppSettings through the ASP.NET Web Site Administration Tool, too (Project menu -> ASP.NET Configuration).

For values which you envisage changing more often and while the site is up and running, it's reasonable to use an XML file, lightweight database (such as SQLite or SQL Server Compact) or even a text file for these settings.

Dave R.
+2  A: 

I usually add a "type" field to my settings table so that I only retrieve the group of settings needed this works for me as a way of grouping like settings and retrieving them at once.

jangeador
This is a good idea. Thanks for the suggestion.
Pretzel
A: 

If you need to save settings, you can always save them in a custom configuration file.

I did just that a while back, and I have the code available to do it here.

George Stocker