I noticed in the documentation that a WebConfigurationManager is the "preferred" way to get settings for a Web application, but I also noticed that a plain old ConfigurationManager works as well.

Now, from my OO perspective, I'm looking for an easy way to hook into .NET configuration that isn't coupled to a specific implementation (ASP.NET). With that idea, using a generic ConfigurationManager seems to be a more appealing alternative, so my question is "Why use the WebConfigurationManager?". I'm sure there's a good reason, but I couldn't find an explanation in the docs, just a recommendation.

Will a plain old ConfigurationManager get the job done for the Web?

Note that the WebConfigurationManager has methods to open a web configuration object on design (not-readonly) time, which allows you to modify values on the configuration. Although the value can be read using ConfigurationManager also.

 

The following code will add a connection string to the configuration.

 

        Configuration cfg = WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);

        ConnectionStringsSection connections = (ConnectionStringsSection)cfg.GetSection("connectionStrings");

       

        if ( connections.ConnectionStrings["MyConnName"] == null )

            connections.ConnectionStrings.Add(new ConnectionStringSettings("MyConnName", "MyConnValue"));

       

        cfg.Save();

 

The following code will only read the connection string.

 

                 Response.Write(ConfigurationManager.ConnectionStrings["MyConnName"] + "<br />");

Thanks a ton, josere.

So is it safe to say that if all we require for the configuration is read-only access, we can use the ConfigurationManager? There will be no penalty with loss of (read-only) functionality?

Also, any word on why the functionality was split into the two, completely independant managers? I mean, presumably they serve the same purposes: to open, read, and write to config files, and save for 2 or 3 functions (not counting functionally equivalent though differently named functions like "OpenWebConfiguration" vs. "OpenExeConfiguration") the method signatures are identical, yet they don't even share a common interface or ancestor (they both inherit from object and don't implement anything). I understand that the underlying logic for manipulating the files may differ, but it seems to me the the framework can have a common base class or, to spice up the flexibility, a strategy class property to handle the nuances.

This seems like a much more elegant, OO approach. As it is now, a class that I think developers want to be generic is coupled to one environment (web or desktop), leaving us to write our own adapters if we want to create an abstracted confiiguration tier.

What gives?

So is it safe to say that if all we require for the configuration is read-only access, we can use the ConfigurationManager?

Sorry, I guess you can infer that from what I said. The truth is that you can have read-only access though WebConfigurationManager too. The same read-only statement I wrote before can be changed to:

uses System.Web.Configuration;
[...]
Console.WriteLine(WebConfigurationManager.ConnectionStrings["MyConnStr"].ConnectionString);

Note that this will work on a client .exe as well, as long as you are referencing System.Web.dll and using System.Web.Configuration namespace.

This way of accessing the configuration is called Configuration Runtime API. It’s faster and simpler. It uses the static GetSection() method.

However, if you need to open a specific configuration on a client .exe you'll need ConfigurationManager.OpenExeConfiguration() which will return a Configuration object instance. This way of accessing the configuration is called Configuration Design API. It's more powerful and flexible.

In synthesis, accessing design web configuration will require WebConfigurationManager and accessing design desktop configuration will require ConfigurationManager. For runtime configuration you can use either object. I'll use ConfigurationManager though. It has three letter less to type and, by default, it doesn't require the <%@ Import %> directive on web pages.

There will be no penalty with loss of (read-only) functionality?

Note that some configuration sections can choose to be hidden on runtime, usually for security reasons, so not all sections are available. Opening design configuration requires High trust on web applications.

If you run the following code in a .aspx page, you'll see the differences on Runtime and Design for all sections on the web app.

void Page_Load() {
Configuration cfg = WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);
PrintSections( cfg.Sections);
PrintGroups( cfg.SectionGroups );
}

void PrintSections(ConfigurationSectionCollection sections) { 
   foreach(ConfigurationSection section in sections) {
      Response.Write(section.SectionInformation.SectionName + "<br />");
      Response.Write("Design: [" + section + "]<br />");
      object o = ConfigurationManager.GetSection(section.SectionInformation.SectionName);
      if ( o == null ) {
         Response.Write("Runtime: [null]<br />");
      }
      else {
         Response.Write("Runtime: [" + o.GetType().ToString() + "]<br />");
      }
   }
}

void PrintGroups(ConfigurationSectionGroupCollection groups) {
   foreach (ConfigurationSectionGroup group in groups) {
         PrintSections(group.Sections);
   }
 }

Also, any word on why the functionality was split into the two, completely independent managers?

I guess that at some point they grew so big that need to be split on two. The generic configuration is big enough (It requires its own assembly System.Configuration.dll). But I think you are right. They could have shared a common ancestor.

Thanks again, Jose. Very helpful.

The PrintGroups() method above is not complete. A recursive call is necessary.

void PrintGroups(ConfigurationSectionGroupCollection groups) {
   foreach (ConfigurationSectionGroup group in groups) {
      PrintSections(group.Sections);
      PrintGroups(group.SectionGroups);
   }
}

When I started using .net 2.0 VS 2005, I used WebConfigurationManager.

But now I converted a web project to the Web Application Project, and found that WebConfigurationManager stop working, but the ConfigurationManager works fine.

Is this a known issue? Anyone can elaborate?

Thanks

josere:

WebConfigurationManager has methods to open a web configuration object on design (not-readonly) time

That's exactly what I need now! I'm implementing control, and its designer should access the values from web.config section.

How can I load System.Configuration.Configuration object and my ConfigurationSection in design-time (from within my ControlBuilder or CollectionEditor inherited class or whatever)?

 I have an another problem. I'm writing a class which use ConfigurationSection and loads configuration section like this:

 

protected GlobalConfigSection GcSection
        {
            get{
                m_GcSection = (GlobalConfigSection)ConfigurationManager.GetSection("GlobalConfigSection")??new GlobalConfigSection();
                return m_GcSection;
                }
        }

 

So, GcSection is an attribute of some class. I don't know if class instance is used in WebForm or service application, so how can i access Configuration object used by ConfigurationManager?

 

Thanks for any valuable question,

tuhfa:

When I started using .net 2.0 VS 2005, I used WebConfigurationManager.

But now I converted a web project to the Web Application Project, and found that WebConfigurationManager stop working, but the ConfigurationManager works fine.

Is this a known issue? Anyone can elaborate?

WebConfigurationManager wants write access to the root web.config file for the machine, and by default only administrators have that kind of access. I've opened it as an issue in connect, if you'd like to comment.

http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=358766