Dryadwoods
Dryadwoods

Reputation: 2929

Problems with Web.config and App.config

Intro:

My scenery:

Problems:

.

Upvotes: 5

Views: 11214

Answers (4)

Fábio Batista
Fábio Batista

Reputation: 25270

As Precipitous suggested, try Castle Windsor:

http://www.castleproject.org/container/

You're doing Inversion of Control manually. Windsor will take the burden off of you.

Upvotes: 0

ctford
ctford

Reputation: 7297

You could store the credentials in a secondary config file referenced from web.config as follows:

<appSettings file="AppSettings.config"/>

You would still need to be careful to avoid editing conflicts on the external file.

Upvotes: 5

Dryadwoods
Dryadwoods

Reputation: 2929

Ok guys, while I was waiting for some help I put my hands to work and I was able to find a good solution (in my opinion of course :P).

Let me share it with you:

So, I have one web application, or one console application, or some other kind of application, and lots of class library, and I need to store informations (different per Visual Studio project) that will change during runtime.

Storing this information inside the Web.config or App.config is not a good idea for the many problems it takes.

The other way I see it is to have one XML config file per project.

Each application will read his own XML and add it to the Cache with CacheDependency (will expire when the XML config file is updated). This way we will not need to read the configuration all the times, and we also know when the configuration is changed.

IMO THIS IS THE FASTEST AND EASIEST WAY TO SOLVE THE PROBLEM, no need to use 3rd party frameworks (neither the time it takes to learn/program it).

.

Example code:

    protected void Page_Load(object sender, EventArgs e)
    {
        DBConfiguration cachConf;
        cachConf = Cache["cachConf"] as DBConfiguration;
        if (cachConf == null)
        {
            cachConf = new DBConfiguration();

            XmlDocument doc = new XmlDocument();
            doc.Load(HttpContext.Current.Request.PhysicalApplicationPath + "bin/MyConf.xml");
            XmlNodeList xnl = doc.GetElementsByTagName("username");
            XmlElement xe = (XmlElement)xnl[0];
            cachConf.Username = xe.InnerText.ToString();
            xnl = doc.GetElementsByTagName("password");
            xe = (XmlElement)xnl[0];
            cachConf.Password = xe.InnerText.ToString();               

            Cache.Insert("cachConf", cachConf, 
                new System.Web.Caching.CacheDependency(
                    HttpContext.Current.Request.PhysicalApplicationPath + "MyConf.xml"),
                    DateTime.Now.AddMinutes(60), TimeSpan.Zero,
                    System.Web.Caching.CacheItemPriority.Default,
                    new System.Web.Caching.CacheItemRemovedCallback(
                        CacheItemRemovedCallBack));
        }
        LabelUsername.Text = cachConf.Username;
        LabelPassword.Text = cachConf.Password;            
    }

    private void CacheItemRemovedCallBack(string key, object value, CacheItemRemovedReason reason)
    {
        //Response.Write("Hello world"); 
    }

Upvotes: 5

Precipitous
Precipitous

Reputation: 5343

Problem 1 - Runtime changes: The solution that Microsoft hopes you apply to this type of problem is to simply keep the web server stateless. When an ASP.NET application recycles, it lets existing requests complete new requests start on a new process. For background, read about IIS Process Recycling. A change to web.config recycle the worker process, but users will not notice this (unless you keep state in the web server process). That's the MS design.

If you want to monitor for changes without recycling a process, you'll want something other than default web.config behavior. An example that comes to mind are cruise controls project files. They have a component that maps objects to and from xml, using that, you can use the FileSystemWatcher class to monitor for changes.

Problem 2 - Custom configurations: It sounds like you have components from different libraries that have different dependencies. Your main assembly needs a means to instantiate a service, with a given set of dependencies. The MS data provider model is cool, but not this cool.

To be this cool, use an inversion of control container, because this is exactly what they do. I like autofac (because I like the Philip K Dick reference), but castle windsor is great.

Now, if you are talking about changes databases or data providers on the fly, it may be that configuration is not the right place. If your are reporting against x databases of y types, you need a central repository of that database information, and a configuration file is not the right place, nor is an IOC container the right solution.

Upvotes: 2

Related Questions