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

Question

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

Наиболее распространенным является:

• Веб-сервер (IIS)
• База данных (SQL)

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

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

asp.net (.net?) Уже поддерживает модель с наследованием web.config, что было бы идеальным сценарием, однако это работает только для каталогов.

Было бы здорово, если бы у нас было

• web.config <- под управлением версией </li>
• web.machine.config <- не под контролем версий </li>

Конечно, я открыт для лучших предложений о том, как люди решают эту проблему.

Как и, может быть, иметь:

• web.base.config <- под управлением версией </li>
• web.machine.config <- не под контролем версий </li>

И наличие сценария сборки, который создает файл web.config, объединяя их?

Заранее спасибо, Стивен.

---

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

Похоже, что следующий против может иметь способ справиться с этим:

http://blogs.msdn.com/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx

---

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

Возможно, выполнимо сегодня с массовым обновлением xml:

http://blogs.microsoft.co.il/blogs/dorony/archive/2008/01/18/easy-configuration-deployment-with-msbuild-and-the-xmlmassupdate-task.aspx

---

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

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

По сути, мы храним Web.base.config в контроле версий и запускаем его через преобразование, чтобы сгенерировать Web.config для события сборки.

Похоже, что vs2010 действительно поможет с гораздо более дружественной версией этого.

Answer 1

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

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

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

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

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

Таким образом, мы создали «инкапсуляцию» информации и можем легко справляться с такими проблемами, как контроль исходного кода, развертывание и тому подобное.

Answer 2

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

Вот пример xslt build build (хотя вы можете захотеть написать его в соответствии со своими собственными стандартами кодирования) и пример мирского преобразования 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> 

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

Answer 3

VS 2010 предоставит вам много возможностей для управления файлами web.config для различных конфигураций ... Пожалуйста, ознакомьтесь .

Answer 4

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

1. Специфическое приложение
2. Специфичное развертывание

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

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

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

Преимущества такой договоренности ...

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

Answer 5

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

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

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

Разница между Web.config и Machine.config

Answer 6

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

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

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