ConfigurationManager vs WebConfigurationManager

Проблема была в следующем:

Писалась библиотека, которая должна одинаково хорошо работать как в WebApp, так и в ClientApp. Настройка библиотеки для работы, можно было бы осуществлять, как непосредственно (через установку свойств статических классов), так и через *.config приложения. Всё бы ничего, только вот незадача для получения данных из конфига в WebApp используется класс WebConfigurationManager, а для ClientApp используется ConfigurationManager. В общем-то они делают реализацию для одного и того же абстрактного класса. Начал думать, как отличить в каком контексте работает приложение. Было придумано куча вариантов, включая получение пути к конфигурационному файлу (из System.AppDomain.CurrentDomain.SetupInformation.ConfigurationFile и не париться вообще в отличении контекстов) и разбор его вручную чтобы найти свою секцию и забрать из неё данные. Но всё это как-то не прозрачно, да и запутано. А потом я вспомнил про слово-оператор as.... и получилось достаточно компактно и понятно:

DataMapConfigSectionHandler dmcsh;

dmcsh = ConfigurationManager.GetSection("ntlDataMapConfig") as DataMapConfigSectionHandler;

if (dmcsh == null)

{

dmcsh = WebConfigurationManager.GetSection("ntlDataMapConfig") as DataMapConfigSectionHandler;

}

После этого нужно dmcsh проверить на null, так как dmcsh может равняться null, если секция, которую вы указали не найдена.

Правда, такой подход всё равно накладывает определённые нехорошести: классы ConfigurationManager и WebConfigurationManager находятся в разных сборках соответственно System.Configuration.dll и System.Web.dll. CLR придётся загрузить их обе, и соответственно отъесть немного памяти, если для вас это критично, то, наверное всё-таки придётся загружать вручную конфигурационный файл и парсить его ручками, как XML документ.