Как настроить несколько модулей с использованием файлов конфигурации .net

Question

У меня есть несколько .net модулей / библиотек, на которые я ссылаюсь из своего основного приложения. Каждый из модулей / библиотек может быть настроен, и после того, как я соберу их, у каждого из них будет файл конфигурации, такой как MyModule1.dll.config, MyModule2.dll.config.

Когда я создаю основное приложение, файл app.config выводится в выходной каталог.

Мне интересно, как настроить MyModule1, MyModule2 и т. Д. Должен ли я включать разделы конфигурации для каждого в файле app.config или у меня должен быть отдельный файл конфигурации для каждого модуля, в который я загружаю файл конфигурации для каждого из них? Отдельная конфигурация для модуля описана здесь: http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/2710647c-6414-42c4-90b7-fd7603f55ae0/? Это будет означать, что я бы скопировал MyModule1.dll.config и MyModule2.dll.config в выходной каталог.

Кто-нибудь может дать мне несколько советов о том, как лучше всего это сделать?

Edit:

Из MyModule1.dll я могу явно загрузить MyModule1.dll.config, используя

Uri p = new Uri(System.Reflection.Assembly.GetExecutingAssembly().CodeBase);
Configuration config = ConfigurationManager.OpenExeConfiguration(p.LocalPath);

но если MyModule1.dll ссылается и использует одну из моих общих библиотек MyCommonLib.dll, как я могу настроить MyCommonLib.dll из того же файла конфигурации MyModule1.dll.config?

Answer 1

Не зная точно, какая у вас конфигурация, я бы сказал, что вы должны объединить файлы конфигурации с основной конфигурацией exe. Таким образом, вам не нужно никакого дополнительного кода, чтобы все заработало. Именно так работает большинство приложений .NET, и это то, что большинство людей ожидают. (Посмотрите на web.config - там появляются разделы со всего мира.)

Если вы используете строго типизированные настройки в свойствах, которые предлагает Visual Studio, это будет работать нормально. Вы просто объединяете configSections и копируете определенные части из каждого файла конфигурации в основной. Мы сделали это какое-то время, и это отлично сработало.

Answer 2

Если вы используете систему папок Properties в Visual Studio и хотите, чтобы Visual Studio автоматически синхронизировал их, вы захотите использовать подход конфигурации для модуля, который вы описали, просто для повышения производительности.

В качестве альтернативы, если вы просто имеете дело с записями или записями, это может быть проще из одного конфигурационного файла. Мой единственный совет здесь заключается в том, чтобы пойти с тем, что является самым простым и самым естественным способом для тех, кто еще / будет работать над проектом.

Answer 3

Все зависит от того, насколько ваши библиотеки отделены от вашего приложения.

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

Если это только одно приложение, используйте один файл конфигурации. Тогда все ваши настройки находятся в одном месте.

Answer 4

Я бы посоветовал вам использовать exe.config, если вам не нужно слишком много информации о конфигурации.

Или вы можете рассмотреть возможность использования инфраструктуры управления конфигурациями, подобной тем, которые включены в Microsoft Enterprise Library или Spring.net

Answer 5

Рассматривали ли вы использование Spring.NET для управления вашей конфигурацией? Конечно, вы также получаете массу других функций, но конфигурация - отличное место для начала работы с Spring.

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