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





Вы можете использовать событие Post-build (Properties -> Build Events) в своих «дочерних» проектах, чтобы скопировать файл конфигурации из главного проекта в другие, например:
copy /Y c:\path\to\master\project\app.config $(TargetPath).config
exit 0
(«Выход 0» в последней строке предотвращает ошибку сборки).
Чтобы иметь отдельные файлы конфигурации для разных целей сборки («RELEASE», «DEBUG» и т. д.), Вы можете отредактировать файл .csproj (или .vbproj) в NOTEPAD.EXE, чтобы добавить тег AppConfig для каждой из целевых групп, например это:
<PropertyGroup Condition = " '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>false</Optimize>
<OutputPath>.\bin\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<AppConfig>debug.app.config</AppConfig>
</PropertyGroup>
<PropertyGroup Condition = " '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>false</Optimize>
<OutputPath>.\bin\Devel\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<AppConfig>release.app.config</AppConfig>
</PropertyGroup>
Обратите внимание на новые теги <AppConfig>, присутствующие в каждой группе.
Для большого количества настроек, необходимых для нескольких приложений, я бы поместил эту конфигурацию в центральный репозиторий, например база данных, файл в общем месте.
Чтобы использовать разные версии файла конфигурации для разных сред, создайте конфигурацию сборки для каждой из разных сред и файл конфигурации, названный в честь среды, например:
производство production.app.config тест test.app.config
Затем вы можете использовать событие перед сборкой, чтобы скопировать правильную конфигурацию поверх app.config по умолчанию в вашем проекте. Затем это будет скопировано в ваш выходной каталог как обычно.
Событие перед сборкой будет похоже на приведенное выше, просто используйте $ (Configuration), чтобы получить соответствующий файл для нужной среды.
Вы можете объединить это с приведенным выше, чтобы скопировать общие файлы конфигурации для конкретной сборки в каждый проект.
Центральному репозиторию по-прежнему нужна некоторая информация о локальной конфигурации (например, ConnectionString или что-то еще, что требуется для доступа к нему). Кроме того, некоторая информация должна быть разделена между локальным хранилищем и хранилищем (например, ведение журнала, чтобы иметь возможность сообщать о «ранних» ошибках). Все еще выполнимо, конечно, но требует дополнительных размышлений.
Я полагаю, что конфигурацию сборки нужно будет выполнить в Visual Studio - я обнаружил, что это нормально, но требует довольно большого управления, поскольку очень легко случайно изменить конфигурацию сборки. Но хороший ответ!
Ник Р. - Я делал это только в Visual Studio, но не понимаю, почему MSBuild не может сделать это тоже.
Christian.K - Да, действительно, но только в небольшом количестве, и я все же рекомендую возможность настройки и локального журнала (как вы говорите, очень полезно на ранних этапах сбоя)
Вместо того, чтобы добавлять элементы <add> в раздел <appSettings> вашего файла конфигурации, вы можете добавить атрибут file= к элементу <appSettings>, чтобы он загрузил эти данные из другого файла. Затем вы можете сохранить свои общие настройки в этом общем файле.
См. Элемент appSettings (схема общих настроек) в библиотеке MSDN.
Я делаю это. Я просто разочарован тем, что файл Settings.settings (я предпочитаю его, поскольку он сильно типизирует настройки и позволяет легко обновлять конфигурацию) не предлагает эту функцию.
Вы также можете поместить параметры конфигурации в файл machine.config, чтобы поделиться ими между несколькими приложениями. Однако это делает развертывание более проблематичным.
Можно использовать Символьные ссылки NTFS для совместного использования файла .config .NET. Я видел, как это успешно используется в решении, состоящем из приложения ASP.NET, консольных приложений и многого другого.
Мне это нравится, но он добавляет еще один шаг развертывания.
У меня был тот же вопрос, но я так и не нашел решения. Я буду следить за этой веткой.