Изменение customErrors в web.config полудинамически

Question

Основная идея заключается в том, что у нас есть тестовая среда, которая имитирует Production так customErrors = "RemoteOnly". Мы только что создали тестовый жгут, который работает против тестовой среды и обнаруживает перерывы. Мы хотели бы, чтобы он смог отбросить подробную ошибку. Но мы не хотим превращать customErrors = «On», потому что тогда он не имитирует Production.

Я огляделся и много думал, и все, что я придумал, невозможно. Я не прав по поводу любого из этих пунктов?

• Мы не можем включить customErrors во время выполнения, потому что при вызове configuration.Save() - он записывает файл web.config на диск и теперь он отключен для каждого запроса.
• Мы не можем символизировать файлы в новый каталог верхнего уровня с собственным web.config, потому что мы на окнах, а подрывная деятельность в окнах не содержит символических ссылок.
• Мы не можем использовать URL-сопоставление, чтобы создать пустую папку dir2 со своим собственным web.config и сделать файлы в каталоге dir1, как представляется, в каталоге dir2 - не применяется web.config
• Мы не можем скопируйте все aspx-файлы в dir2 с помощью собственного web.config, потому что ни одна из ссылок не будет последовательной, и это ужасное хакерское решение.
• Мы не можем изменить CustomErrors в web.config на основе имени хоста (например, добавить еще одну запись DNS на тестовом сервере), потому что это не возможно/поддерживаются
• Мы не можем сделать виртуальные проделки каталог, чтобы заставить его работать.

Если я не уверен, есть ли способ сделать то, что я пытаюсь сделать? Включить customErrors на сайте в определенных обстоятельствах (имя DNS или даже значение запроса)?

Answer 1

Если у вас есть customErrors = "On" или "remoteOnly", информация об ошибке не исчезает правильно? Я имею в виду, что вы все равно можете получить к нему доступ и зарегистрировать его в другом источнике, используя страницу пользовательских ошибок.

Почему у вас нет собственной страницы ошибок в журнале производства, где вы можете получить доступ к этой информации, например, к очереди сообщений или журналу событий приложения? Когда жгут пробивает перерыв, он просто должен быть достаточно умным, чтобы выполнить поиск в нужном месте для полной информации об ошибке.

Другая вещь, которую следует учитывать в любом случае.