Как правильно спроектировать логику отработки отказа, если сборка (.dll) не может найти файл web.config?
Предыстория: у меня есть код нашего сайта, красиво модулированный в две разные .dll. Для простоты давайте назовем их:
- website.dll
- commonengine.dll
Код веб-сайта и файлы .aspx / .ascx обращаются к общей библиотеке для всех элементов уровня данных. Что касается строк подключения, общий двигатель, в свою очередь, обращается не к app.config, а к файлу web.config веб-сайта (это мое собственное предпочтение - я предпочитаю, чтобы все производственные константы были в одном месте). Код веб-сайта иногда (очень редко) нуждается в доступе к содержимому этого файла web.config. Пока все хорошо (хотя и не совсем чисто).
Вот проблема. Я написал третий модуль. Это служба Windows (в частности, это средство проверки / обработки POP3 - для обработки запросов почтовых ящиков и использования commonengine.dll для некоторых вещей на уровне данных).
Проблема заключается в том, что служба Windows обращается к commonengine.dll, а commonengine.dll не может нигде найти web.config, поскольку, в конце концов, это служба Windows (.exe) и не находится в каталоге веб-сайта.
Какая здесь правильная проверка / логика для использования app.config, когда файл web.config не может быть найден? Может ли какой-нибудь гуру по настройке ASP.NET дать мне какое-то руководство? Большое спасибо, если так.