Объявление в AppDomain и config

Question

У меня есть приложение Windows в .NET, которое использует несколько уровней файлов конфигурации. По причинам, не зависящим от моего приложения, приложение состоит из проекта приложения Windows (.exe) и нескольких DLL, каждый из которых имеет свой собственный файл app.config.

Я успешно разобрался, как читать конфигурационный файл для каждой DLL, используя (в C#)

ConfigurationManager.OpenMappedExeConfiguration("my DLL's config file path", ConfigurationUserLevel.None); 

Это прекрасно работает - я могу подтвердить, что я получаю объект конфигурации от этого метода, когда указал к файловому имени моего конфигурационного файла моей DLL («foo.dll.config»). Однако, когда я пытаюсь получить доступ к настраиваемому разделу конфигурации, я получаю исключение, говоря, что тип данных для моей настраиваемой секции конфигурации не найден.

Что еще мне нужно сделать, чтобы получить информацию о типе, доступную моему коду при загрузке файла конфигурации таким образом?

Answer 1

Несчастливо, но верно: способ справиться с этим заключается в том, чтобы скопировать конфигурацию из файлов .dll.config в конфигурационный файл приложений. Единственное исключение имеет какое-то отношение к системе настроек, используемой в Windows Forms. Я думаю, что для вас OpenMappedConfiguration, но я не уверен.

Я никогда не знал, почему они не унифицировали это в .NET 2.0 и не решили проблему. Может быть, я должен спросить.

---

Ранее в тот же день, я задал вопрос, как это, как относится к WCF, в Осло Форум по MSDN (http://social.msdn.microsoft.com/Forums/en-US/oslo/thread/c93ee7f3-4f9b-4044-b1f0-43ad72fb508d). Поскольку я искал сообщение в блоге или какой-то другой ответ (как я сказал выше, «возможно, я должен спросить»), ответ на мой пост в форуме прибыл.

Длинный рассказ короткий и несколько вялый, ответ таков: они не исправили это в .NET 2.0, потому что они ждали, когда Осло решит проблему.

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

Спросите меня завтра, и я могу чувствовать себя по-другому, но сейчас, я могу быть собиранием религии Осло ...