Различия в поведении между System.Web.Configuration.WebConfigurationManager и System.Configuration.ConfigurationManager - PullRequest
Новая
       44

Различия в поведении между System.Web.Configuration.WebConfigurationManager и System.Configuration.ConfigurationManager

12 голосов
/ 14 января 2010

У меня возникли проблемы на тестовом сервере с веб-сайтом ASP.NET. Я обманываю, и у меня был дом каталог веб-сайта по умолчанию указывает на неправильное место. Когда я попробовал: 

ConfigurationManager.ConnectionStrings["connectionString"];

вернул ноль, но 

using System.Web.Configuration;

/* ... */

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

WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);

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

вернул правильную строку подключения.

Каковы все различия между двумя подходами?

РЕДАКТИРОВАТЬ: Что я действительно спрашиваю, так это то, почему сбой подхода ConfigurationManager происходит, когда домашний каталог установлен неправильно, но в противном случае он выполняется, а WebConfigurationManager выполняется независимо от того, правильно ли установлен домашний каталог? Есть ли другие различия, например, предположения об управлении доступом?

Ответы [ 2 ]

31 голосов
/ 14 января 2010

Попробуйте:

Поместите точку останова там, где находится оператор 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 : null , что правильно для моего веб-приложения.

Что вы получаете для конфигурации Source source ???

Немедленное предположение

ConfigurationManager.ConnectionStrings["connectionString"]; может искать конфигурационное местоположение, которое не обязательно совпадает с корневым каталогом веб-приложения web.config. Вероятно, он ищет в каталоге Windows (например, в другом месте или для machine.config). Хотя пытаюсь найти подходящий тест для этого.

Намерения каждого менеджера

System.Configuration. ConfigurationManager может обращаться к XML-формату конфигурации .NET, что означает, что он читает оба:

  • веб-конфигурации (т.е. файл web.config в ASP.NET)
  • и не веб-конфигурации (например, файл app.config - автономное консольное приложение, приложение Windows и т. Д.)

и выражает те аспекты, которые являются общими для типов конфигурации. Это менеджер конфигурации общего назначения. (Однако, несмотря на эту возможность просмотра обоих типов конфигов, вы должны использовать его для конфигов приложения, потому что веб-менеджер посвящен веб-конфигам, как описано далее ...)

System.Web.Configuration. WebConfigurationManager делает почти то же самое, но представляет собой «вебизированную» версию менеджера конфигурации, предоставляющую доступ к веб-аспектам ASP.NET, связанным с веб-интерфейсом. конфигурация (например, файл web.config в ASP.NET).

Сходство

См. Сходства элементов между ConfigurationManager. * и WebConfigurationManager. *

Оба менеджера могут, например, получить доступ к свойству AppSettings и свойству ConnectionStrings. Действительно, оба эти параметра являются общими для обоих видов конфигурации и даже находятся на одном уровне в документе XML.

Таким образом, есть много общего,

Поведенческие различия

Доступ к конфигурации : ConfigurationManager имеет методы для открытия конфигов автономного приложения (то есть App.config Myprogram.EXE) относительно приложения EXEC, тогда как WebConfigurationManager имеет методы для открытия веб-конфигурации ASP.NET относительно корневого каталога его веб-приложения на веб-сайте.

Вот базовый app.config (например, открытый через "C: \ winapp \ app.config" из папки на диске с помощью ConfigurationManager ) 

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

А вот базовый web.config (например, открываемый через "~", означающий корень веб-сайта с помощью WebConfigurationManager ) 

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

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

</configuration>

Обратите внимание на сходство. Также обратите внимание, что в веб-конфигурации есть дополнительный элемент system.web для ASP.NET.

Эти менеджеры расположены в разных сборках.

  • ConfigurationManager: System.Configuration.dll
  • WebConfigurationManager: System.Web.dll
1 голос
/ 14 января 2010

Первый класс обеспечивает доступ к общим файлам конфигурации клиента (например, app.config), а второй - к файлам веб-приложения (например, web.config).

...