Нужен способ управления файлами app.config

Question

Сейчас четверо из нас работают над решением.Решение состоит из центрального исполняемого проекта (службы Windows) и ряда решений библиотеки классов.В службе Windows есть файл app.config, но для параметра «Копировать в выходной каталог» для него по какой-то причине установлено значение «Не копировать», поэтому мы можем игнорировать его в этом обсуждении.

Существует два разныхПроекты библиотеки классов, в которых есть файлы app.config.В одном из проектов это копируется в папку bin \ Debug как MyClassLibrary.dll.config, в то время как в папке bin \ Debug другой библиотеки DLL есть как MyOtherClassLibrary.dll.config, так и app.config.Я не уверен, как это произошло.

Это все файлы app.config в решении.

В решении есть проект MSTest.У него есть несколько классов с атрибутами [TestClass], каждый в своем собственном файле .cs.Когда я смотрю на папку bin \ Debug этого проекта, я нахожу в ней MyClassLibrary.dll и App.config, но не MyOtherClassLibrary.dll.Это странно, но вот что я вижу.

Когда я запускаю один из этих тестов, как вы знаете, файлы копируются в специальную папку тестов в папке TestResults решения.Когда я смотрю в эту папку, я нахожу только файл MyTestProject.dll.config.И когда я открываю это, его содержимое совпадает с файлом app.config.

Что здесь происходит?Я думал, Visual Studio объединила все файлы конфигурации вместе?Отсутствие настроек в файле MyClassLibrary.dll.config (очевидно) нарушает код, который на него опирается.

Как мы можем это исправить?

Tony

EDIT:

Я только что дважды проверил папку MyClassLibrary bin \ Debug, в которой есть и app.config, и MyClassLibrary.dll.config, поэтому я думаю, что то, что я видел в MyOtherClassLibrary, нормальноНам просто нужен способ управлять всеми этими настройками.

Answer 1

Нет, VS НЕ объединяет файлы конфигурации вместе.Он этого не делает, потому что возможно иметь решение, которое генерирует два или более исполняемых файла в качестве проектов.Даже для проектов, которые всегда заканчиваются как библиотеки классов и в которых всегда есть только один исполняемый файл, объединять app.configs не рекомендуется из-за разделения интересов;библиотека проекта должна быть «черным ящиком», к которому для ссылки на код нужен только внешний интерфейс посредством создания экземпляров методов и вызова методов.App.config и его информация по определению являются деталями реализации, о которых должен знать только проект, который нуждается в них, а НЕ проекты, ссылающиеся на них.Кроме того, если вы перекомпилировали библиотеку проекта независимо от другого исполняемого файла и просто вытолкнули новую DLL, как тогда будут объединены файлы конфигурации?

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

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

Answer 2

Просто помните, что с конфигурационным файлом (например, с файлами web.config и app.config) происходят две вещи:

1. Файл развертывается как есть.Он может быть подвергнут преобразованиям, но файл развернут с таким именем, как оно.

2. Он компилируется как принадлежащий сборке.Поэтому мой проект с именем ProjectOne будет иметь файл App.Config , скомпилированный и переименованный в ProjectOne.dll.config (при условии, что моя сборка для ProjectOne равна "ProjectOne")

Это важно, потому что все дело в сфере.Это переименование разработано специально, поскольку оно по-прежнему позволяет сборке проекта сначала получить доступ к своему собственному файлу конфигурации.Они будут иметь приоритет над теми, которые есть у самого app.config из сценария 1.

Вы можете предотвратить возникновение сценария 2, изменив свойства файла так, чтобы MSBuild не касался файла.Затем он может попытаться развернуть его как есть.В этой ситуации он будет перезаписывать все ранее развернутые на основе порядка сборки.

Answer 3

Вы вносите свои настройки в основную конфигурацию или внедряете что-то, что объединяет некоторые при сборке, я коснусь этого в некоторой степени здесь: Visual studio 2010 - для каждого разработчика, компьютера или среды. Параметры конфигурации

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

Answer 4

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