Обработка web.config различия через несколько машин при использовании управления версиями

Один из подходов, который я иногда использую, - это разделение раздела, относящегося к среде, в отдельный файл конфигурации, который обычно исключаются из развертывания (за исключением первого раза или изменения их структуры):

Пример для строк подключения: В web.config:

<connectionStrings configSource="connections.config"></connectionStrings>

Файл connections.config (который обычно не включается в развертывание; поэтому он не изменяется):

<?xml version="1.0"?>
<connectionStrings>
    <add name="connectionName" connectionString="[connection string goes here]"/>
</connectionStrings>

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

То, что вы описываете, очень похоже на использование файла Machine.config для хранения строк подключения. Я еще не видел этого, так что вы пробовали? Похоже, вы можете использовать глобальный Web.config, который также находится рядом с вашим Machine.config.

Несколько ссылок:

Иерархия и наследование файла конфигурации ASP.NET

Разница между Web.config и машиной. config

Мы не храним настройки среды в web.config. Они хранятся в базе данных.

Это позволяет нам выполнять развертывание xcopy и сохранять файл web.config в нашей системе контроля версий.

Доступ к базе данных осуществляется через один ключ реестра.

Конфигурацию приложения можно разделить на две категории.

1. Для конкретного приложения
2. Для конкретного развертывания

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

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

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

Преимущества такого расположения заключаются в ...

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

Хотя решений определенно много, ни одно из них на самом деле не дает вам огромного контроля над сгенерированной конфигурацией, одно решение, которое я отметил в своей редакции, где вы получаете огромный контроль но с накладными расходами, связанными с необходимостью написания файла xslt, использовала задачу сборки xslt для использования шаблона web.config / app.config из системы управления версиями (который я лично называю web.base.config / app.base.config), и используйте файл xslt для преобразования файла конфигурации с контролем версий во время сборки и сгенерируйте файл web.config / app.config.

Вот пример задачи сборки xslt (хотя вы можете захотеть чтобы написать его в соответствии с вашими стандартами кодирования), и пример обычного преобразования xslt, которое изменит значение строки подключения и скопирует все остальное в конфигурации:

<?xml version="1.0" encoding="utf-8"?>  
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxsl="urn:schemas-microsoft-com:xslt" exclude-result-prefixes="msxsl">  
  <xsl:output method="xml" indent="yes"/>  

  <!-- Copy all. -->  
  <xsl:template match="@* | node()">  
      <xsl:copy>  
          <xsl:apply-templates select="@* | node()"/>  
      </xsl:copy>  
  </xsl:template>  

  <!-- Swap connection string. -->
  <xsl:template match="/configuration/connectionStrings/add[@name='my_connection_string_name']">
    <xsl:copy>
      <xsl:apply-templates select="@* | node()"/>
      <xsl:attribute name="connectionString">my replacement connection string value</xsl:attribute>
    </xsl:copy>  
  </xsl:template>

</xsl:stylesheet> 

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