Преобразование Web.config изменить путь к настройкам приложений

У меня есть файл web.config, в котором есть строка подключения и настройки приложения в файле отладки, например:

<connectionStrings configSource="config\connectionStrings-debug.config" />
<appSettings configSource="config\AppSettings-debug.config" />

но когда я перехожу к развертыванию, я вручную меняю это на значение prod:

<connectionStrings configSource="config\connectionStrings.config" />
<appSettings configSource="config\AppSettings.config" />

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


person Eddie    schedule 08.02.2018    source источник
comment
Один из способов, который я видел, это оставить configSource в покое (что означает, что все среды имеют один и тот же путь к вторичному файлу). Затем создайте событие после сборки, чтобы скопировать отладочные версии в вашей среде разработки в общее расположение. И процесс развертывания, который создает версии для конкретной среды.   -  person Joe    schedule 08.02.2018


Ответы (2)


Вы должны быть в состоянии достичь того, чего хотите, с помощью простого преобразования. например.:

<connectionStrings xdt:Transform="SetAttributes" configSource="/new/path" />

То же самое относится и к appSettings.

person Kirk Larkin    schedule 08.02.2018

Существует смехотворное количество способов обойти эту проблему.

Во-первых, иметь две строки подключения, одну для отладки и одну для использования в реальном времени. Используйте свойство Name при объявлении вашей строки, чтобы дать им уникальный идентификатор, который вы можете вызвать из своего кода. Затем вы можете использовать If(System.Diagnostics.Debugger.IsAttached) или какую-либо другую логическую проверку, чтобы определить, какую строку использовать во время выполнения, полученную этим Name.

Другой способ — вытащить ваши файлы web.config и app.config из-под контроля исходного кода (т. е. через VS, добавив в файл git .ignore и т. д.). Их лучше хранить локально в той среде, где они используются. Это, пожалуй, лучшая практика. Если вы не перемещаете файлы конфигурации, вы можете просто оставить их на месте и вообще не иметь этой проблемы.

Вы можете попробовать логику, которая определяет, что использовать динамически, команду препроцессора in-c-when-must-we-use-t">#if DEBUG (который определяет, какой код компилируется на основе того, какой профиль вы используете для этого) и т. д. Тот, который доставит вам наименьшие проблемы в долгосрочной перспективе, тем не менее, ваши файлы конфигурации должны быть уникальными для мест их развертывания.

person CDove    schedule 08.02.2018