.NET .config АД - PullRequest
       46

.NET .config АД

6 голосов
/ 05 января 2011

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

  1. MVC
  2. Консольное приложение
  3. Библиотека классов
  4. Приложение Windows Form
  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 для объяснения, но это не было хорошо задокументировано IMO.

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

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

Спасибо

Редактировать:

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

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

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

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

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

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

Ответы [ 2 ]

4 голосов
/ 05 января 2011

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

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

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

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

Другой подход, при котором структура конфигурации та же, но настройки для каждого приложения, - это настраиваемый раздел конфигурации.

1 голос
/ 05 января 2011

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

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

...