Избегайте унаследованных ошибок ELMAH в субприложении ASP.NET

У меня есть родительское приложение IIS, использующее ELMAH, и дочернее приложение ASP.NET (виртуальный каталог), которое не использует ELMAH. Когда я пытаюсь просмотреть свое дополнительное приложение, я получаю следующую ошибку:

Не удалось загрузить файл или сборку "Elmah" или одну из его зависимостей. Система не может найти указанный файл.

Это понятно, поскольку папка bin моего дочернего приложения не содержит сборок ELMAH.

Проблема, вероятно, в том, что родительский web.config файл содержит следующее:

  <configSections>      
    <sectionGroup name="elmah">
      <section name="security" requirePermission="false" type="Elmah.SecuritySectionHandler, Elmah" />
      <section name="errorLog" requirePermission="false" type="Elmah.ErrorLogSectionHandler, Elmah" />
      <section name="errorMail" requirePermission="false" type="Elmah.ErrorMailSectionHandler, Elmah" />
      <section name="errorFilter" requirePermission="false" type="Elmah.ErrorFilterSectionHandler, Elmah" />
    </sectionGroup>
  </configSections>

Насколько я понимаю, невозможно остановить <configSections> наследование, см., Например, Как остановить наследование ‹configSections› в Web.Config . Есть ли способ запустить мое дополнительное приложение без ELMAH?


person Borek Bernard    schedule 26.08.2014    source источник


Ответы (2)


Вы не можете оставить свое субприложение без ELMAH из-за родительской конфигурации. Однако - поскольку я полагаю, вы не хотите ссылаться на сборки из родительского элемента - вы можете указать своему субприложению найдите сборки в родительской папке bin с конфигурацией проверки.

Таким образом, вашему субприложению не нужно знать, какие сборки существуют для родительского, только то, что если требуется неизвестная сборка, ее можно найти в родительских папках.


Изменить: Это действительно облом. Очистка и удаление тегов конфигурации Microsoft сочла слишком сложным:

<clear /> и <remove /> никогда не были реализованы для configSections и sectionGroups из-за сложности попыток объединить разные определения одних и тех же обработчиков разделов и групп разделов.

Следовательно путь обходной путь. Вы также можете настроить приложения так, чтобы они не были связаны с точки зрения иерархии, если это критично.

person samy    schedule 02.09.2014
comment
Вы не можете оставить свое субприложение без ELMAH из-за родительской конфигурации. Действительно? Это было бы обломом, эти два приложения не имеют ничего общего и не должны наследовать друг от друга. - person Borek Bernard; 02.09.2014
comment
Не могли бы вы расширить свою последнюю строчку? Каким будет обходной путь? Спасибо. - person Borek Bernard; 02.09.2014
comment
Если вы добавите в свое субприложение пробный путь к папке bin родительского приложения, приложение сможет найти любую сборку, которая нужна родительскому объекту, без ссылки на нее. См. Ссылку в ответе - person samy; 02.09.2014
comment
@samy Путь проверки Specifies subdirectories of the application's base directory that might contain assemblies. Итак, как добавить путь проверки к папке bin родительского приложения, родительское приложение вряд ли будет подкаталогом вспомогательного приложения. Я неправильно понял? - person philreed; 07.05.2015

Я обнаружил, что добавление enableConfigurationOverride="false" в определение пула приложений решает эту проблему.

Из документов MSDN:

Необязательный логический атрибут. Значение true означает, что делегированные параметры в файлах Web.config будут обрабатываться для приложений в этом пуле приложений. Если установлено значение false, все настройки в файлах Web.config будут игнорироваться для этого пула приложений. Значение по умолчанию - true.

Есть два метода сделать это, где ChildApplicationName следует заменить на значение имени вашего пула приложений.

Метод 1 (предпочтительный / рекомендуемый):

Выполните следующую команду в appcmd < / a> в режиме администратора:

appcmd.exe set config -section:system.applicationHost/applicationPools /[name='ChildApplicationName'].enableConfigurationOverride:"False" /commit:apphost

Метод 2:

Второй включает прямое редактирование файла %windir%\System32\inetsrv\config\applicationHost.config, что позволяет приложению эффективно игнорировать родительское приложение. По разным причинам я не советую это делать, но оставляю это для потомков.

Чтобы установить это, выполните поиск по имени пула дочерних приложений. Он должен быть под xpath. /configuration/system.applicationHost/applicationPools.

<configuration>
  <system.applicationHost>
    <applicationPools>
      ...
      <add name="ChildApplicationName" enableConfigurationOverride="false" />
      ...
    <applicationPools>
  <system.applicationHost>
<configuration>
person Dan Atkinson    schedule 24.05.2016