.NET .config HELL

Question

У меня есть следующие проекты:

1. MVC
2. Консоль приложения
3. библиотека классов
4. приложения Windows Forms
5. COM библиотека

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

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

Я не совсем понимаю, как создаются файлы конфигурации. В настоящее время я написал простой проект, в котором у меня есть следующее:

1. Библиотека классов для хранения файлов конфигурации. А попытались сделать это через отражение.
2. Приложение Windows, которое должно читать app.config из библиотеки классов.

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

_applicationSettings = ConfigurationManager.OpenExeConfiguration(
        System.Reflection.Assembly.GetAssembly(typeof(WCSConfiguration)).Location 
        ).AppSettings;  

Что я получаю вместо является пустой файл настройки приложения.

библиотека классов имеет следующий App.config:

<?xml version="1.0" encoding="utf-8" ?> 
<configuration> 
    <appSettings> 
    <add key="TestTextKey" value="TestTextValue"/> 
    </appSettings> 
</configuration> 

Я попытался с помощью .GetExecutingAssembly() метод, который я ожидаю, чтобы вернуть сборку кода, который в настоящее время выполняется. Это не сработало, вместо этого оно вернуло сборку приложения Windows.

GetAssembly(type(WCSConfiguration)) вернул правую сборку, однако конфигурационный файл отсутствовал в каталоге bin/debug.

У меня такое чувство, что либо я делаю что-то принципиально неправильное, либо Microsoft не сделала этого достаточно гибким. Я также попытался найти MSDN для объяснения, но это не было хорошо документировано ИМО.

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

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

Спасибо

Edit:

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

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

То, что я хотел бы получить от этого, является хорошим рабочим решением, чтобы его можно было публиковать в Интернете, а другие люди, сталкивающиеся с одной и той же проблемой, не будут тратить дни своего времени.

Морали истории IMO: Используйте как App.config, и Web.config для хранения своего собственного файла конфигурации.

Напишите простой XML-сериализатор для чтения/записи конфигурации и DLL для обслуживания конфигурации.

COM-объекты являются длинной историей и были реализованы с помощью «взлома», поскольку в COM-библиотеках не доступны ни App.config, ни Web.config.

Answer 1

Примечание ConfigurationManager.OpenExeConfiguration необходимо передать имя файла конфигурации, а не исполняемый файл.

Вам необходимо добавить .config на путь к исполняемому файлу. Чтобы получить сборку exe, используйте Assembly.GetEntryAssembly.

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

• Поместите их в свои собственные myStuff.config.
• В коде .NET используйте ConfigurationManager.OpenExeConfiguration, чтобы открыть и получить доступ к myStuff.config.
• Для неинтегрированного кода необходимо будет использовать синтаксический анализатор XML для загрузки и чтения настроек. Если структура конфигурации не очень сложна, это не должно быть слишком сложным для инкапсуляции.
• Поместите путь в myStuff.config в app.config каждого приложения, использующего эту конфигурацию для приложений .NET. (Не-приложения .NET: зависит от того, что работает для этого приложения.)

Другой подход, когда структура конфигурации такая же, но настройки для каждого приложения будут настраиваться.

Answer 2

Несколько общих моментов - добавьте разделы конфигурации dll в файл app.config, вместо того чтобы полагаться на конфигурационный файл dll для получения; и app.config фактически переименовывается в .exe.config при сборке, поэтому вам нужно убедиться, что файл этого имени доступен.

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