I had some trouble on a test server with an ASP.NET website. I goofed, and had the home directory of the Default Web Site pointed to the wrong place. When I tried:
ConfigurationManager.ConnectionStrings["connectionString"];
it returned null, but
using System.Web.Configuration;
/* ... */
var rootWebConfig =
WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);
WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);
rootWebConfig.ConnectionStrings.ConnectionStrings["connectionString"].ConnectionString;`
returned the correct connection string.
What are all the differences between the two approaches?
EDIT: What I'm really asking is, why does the ConfigurationManager
approach fail when the home directory is incorrectly set, but succeeds otherwise, and the WebConfigurationManager
succeeds regardless of whether the home directory is correctly set? Are there any other differences, such as assumptions about access control?
First class provides access to general client config files (such as app.config) and second one for web application's files (such as web.config).
Try This:
Put a breakpoint where your ConfigurationManager statement is and run the following in the Immediate Output window
((ConfigurationSection) ConfigurationManager.GetSection("connectionStrings")).ElementInformation
. My machine reports Source: "C:\Users\John\Documents\Visual Studio 2008\Projects\StackOverflowCode\WebApplication1\web.config" as seen below.Note: The following also shows mine is accessing the ASP.NET web.config.
And when I run
ConfigurationManager.ConnectionStrings.ElementInformation
I get Source:null which is correct for my web app.What do you get for a configuration Source path???
Immediate Assumption
ConfigurationManager.ConnectionStrings["connectionString"];
might look for a config location which isn't necessarily the same as the web application's root web.config. Likely it's looking in a Windows directory (e.g at a different place or for machine.config). Trying to find an appropriate test for this though.Intentions of Each Manager
System.Configuration.ConfigurationManager can access the .NET configuration XML format which means it reads both:
and expresses those aspects that are common to types of configuration. This is a general purpose config manager. (However despite this ability to look at both types of configs, you should use it for app configs because the web manager is devoted to the web configs, as described next ...)
System.Web.Configuration.WebConfigurationManager does pretty much the same thing but is the "webified" version of configuration manager, providing access to ASP.NET web-specific aspects of configuration (e.g. web.config file in ASP.NET).
Similarities
See member similarities between ConfigurationManager.* and WebConfigurationManager.*
Both managers can, for example, access an
AppSettings
property and aConnectionStrings
property. Indeed both these settings are common to both kinds of config and are even located at the same level in the XML document.So there are many similarities however,
Behavioral Differences
Accessing configuration: ConfigurationManager has methods to open standalone app configs (i.e. Myprogram.EXE's App.config) relative to the EXEC app, whereas WebConfigurationManager has methods to open the ASP.NET web config relative to it's web application root directory in the web site.
Here's a basic app.config (e.g. opened via "C:\winapp\app.config" from a disk folder by ConfigurationManager)
And here's a basic web.config (e.g. opened via "~" meaning root of web site by WebConfigurationManager)
Notice the similarities. Also notice the web configuration has an additional
system.web
element for ASP.NET.These managers are located in different assemblies.