System.Web.Configuration.WebConfigurationManager 和 System.Configuration.ConfigurationManager 之间的行为差​​异

发布于 2024-08-17 23:23:15 字数 703 浏览 1 评论 0原文

我在带有 ASP.NET 网站的测试服务器上遇到了一些问题。我搞砸了,有了家 默认网站的目录指向错误的位置。当我尝试时:

ConfigurationManager.ConnectionStrings["connectionString"]; 

它返回 null,但

using System.Web.Configuration;

/* ... */

var rootWebConfig =
    WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);

WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);

rootWebConfig.ConnectionStrings.ConnectionStrings["connectionString"].ConnectionString;` 

返回正确的连接字符串。

这两种方法有什么区别?

编辑:我真正要问的是,为什么当主目录设置不正确时 ConfigurationManager 方法会失败,但在其他情况下会成功,而 WebConfigurationManager 会成功,无论是否主目录设置正确吗?是否还有其他差异,例如有关访问控制的假设?

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?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

策马西风 2024-08-24 23:23:15

试试这个:

在 ConfigurationManager 语句所在的位置放置一个断点,然后在“立即输出”窗口中运行以下命令
((ConfigurationSection) ConfigurationManager.GetSection("connectionStrings")).ElementInformation
。我的机器报告来源:“C:\Users\John\Documents\Visual Studio 2008\Projects\StackOverflowCode\WebApplication1\web.config”如下所示。

注意:以下内容还显示我正在访问 ASP.NET web.config。

{System.Configuration.ElementInformation}
    Errors: {System.Configuration.ConfigurationException[0]}
    IsCollection: true
    IsLocked: false
    IsPresent: true
    LineNumber: 17
    Properties: {System.Configuration.PropertyInformationCollection}
    Source: "C:\\Users\\John\\Documents\\Visual Studio 2008\\Projects\\StackOverflowCode\\WebApplication1\\web.config"
    Type: {Name = "ConnectionStringsSection" FullName = "System.Configuration.ConnectionStringsSection"}
    Validator: {System.Configuration.DefaultValidator}

当我运行 ConfigurationManager.ConnectionStrings.ElementInformation 时,我得到Source< /em>:null 这对于我的网络应用程序来说是正确的。

配置源路径会得到什么???


直接假设

ConfigurationManager.ConnectionStrings["connectionString"]; 可能会查找不一定与 Web 应用程序的根 web.config 相同的配置位置。它可能正在 Windows 目录中查找(例如,在不同的位置或查找 machine.config)。不过,正在尝试为此找到合适的测试。


每个管理员的意图

System.Configuration。ConfigurationManager 可以访问 .NET 配置 XML 格式,这意味着它可以读取:

  • Web 配置(即 ASP.NET 中的 web.config 文件)
  • 和非 Web 配置(例如 app.config 文件 - 独立)控制台应用程序、Windows 应用程序等)

并表达配置类型常见的那些方面。这是一个通用配置管理器。 (但是,尽管能够查看两种类型的配置,您还是应该将其用于应用程序配置,因为 Web 管理器专门用于 Web 配置,如下所述......)

System.Web.Configuration。WebConfigurationManager 的作用几乎相同,但它是配置管理器的“网络化”版本,提供对 ASP.NET Web 特定配置方面的访问(例如 ASP.NET 中的 web.config 文件)。

相似之处

查看 ConfigurationManager 之间的成员相似之处。* 和 WebConfigurationManager。*

例如,两个管理器都可以访问 AppSettings 属性和 ConnectionStrings 属性。事实上,这两种设置对于两种配置都是通用的,甚至位于 XML 文档中的同一级别。

因此,有很多相似之处,但

行为差异

访问配置
ConfigurationManager 具有相对于 EXEC 应用程序打开独立应用程序配置(即 Myprogram.EXE 的 App.config)的方法,而 WebConfigurationManager 具有相对于网站中 Web 应用程序根目录打开 ASP.NET Web 配置的方法。

这是一个基本的app.config(例如,通过ConfigurationManager从磁盘文件夹中的“C:\winapp\app.config”打开)

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings/>
  <connectionStrings/>
</configuration>

这是一个基本的web.config。 config(例如,通过“~”打开,表示WebConfigurationManager 是网站的根目录)

<?xml version="1.0"?>
<configuration>  
    <appSettings/>
    <connectionStrings/>

    <system.web>
        <!-- special web settings -->
    </system.web>

</configuration>

请注意相似之处。另请注意,Web 配置有一个针对 ASP.NET 的附加 system.web 元素。

这些经理位于不同组件中。

  • ConfigurationManager:System.Configuration.dll
  • WebConfigurationManager:System.Web.dll

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.

{System.Configuration.ElementInformation}
    Errors: {System.Configuration.ConfigurationException[0]}
    IsCollection: true
    IsLocked: false
    IsPresent: true
    LineNumber: 17
    Properties: {System.Configuration.PropertyInformationCollection}
    Source: "C:\\Users\\John\\Documents\\Visual Studio 2008\\Projects\\StackOverflowCode\\WebApplication1\\web.config"
    Type: {Name = "ConnectionStringsSection" FullName = "System.Configuration.ConnectionStringsSection"}
    Validator: {System.Configuration.DefaultValidator}

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:

  • web configurations (i.e. web.config file in ASP.NET)
  • and non-web configurations (e.g. app.config file - standalone console app, Windows app, etc.)

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 a ConnectionStrings 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)

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings/>
  <connectionStrings/>
</configuration>

And here's a basic web.config (e.g. opened via "~" meaning root of web site by WebConfigurationManager)

<?xml version="1.0"?>
<configuration>  
    <appSettings/>
    <connectionStrings/>

    <system.web>
        <!-- special web settings -->
    </system.web>

</configuration>

Notice the similarities. Also notice the web configuration has an additional system.web element for ASP.NET.

These managers are located in different assemblies.

  • ConfigurationManager: System.Configuration.dll
  • WebConfigurationManager: System.Web.dll
悲欢浪云 2024-08-24 23:23:15

第一类提供对一般客户端配置文件(例如 app.config)的访问,第二类提供对 Web 应用程序文件(例如 web.config)的访问。

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).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文