Управление web.config для команд в VS2010 и TFS

Ответ 1

Надеюсь, это поможет кому-то. Я использовал эту методологию в течение последних двух месяцев. Это очень легко сделать. Я использую VS 2010 с TFS 2010. Позвольте сломать его:

• Все веб-конфигурационные файлы теперь "DependentOn" "web.config"
• Каждый разработчик или команда нуждается в собственном "[User/Team].Debug.config"
• Файлы конфигурации должны быть преобразованы независимо от того, будем ли мы "издавать" в режиме выпуска или нет.

Вот как это делается:

• Щелкните правой кнопкой мыши веб-проект, который вы хотите сделать, и выберите "Выгрузить проект" (не "Удалить проект" ).

• Щелкните правой кнопкой мыши тот же веб-проект еще раз (теперь он должен быть недоступен) и выберите "Изменить... csproj". Это откроет проект в редакторе Xml.

• Прокрутите страницу вниз до тех пор, пока не найдете раздел, в котором есть все списки "Web.config" . Теперь закомментируйте все элементы "DependentUpon" в Xml.

• Закройте редактор Xml и сохраните изменения. Затем щелкните правой кнопкой мыши на своем проекте и выберите "Обновить". Когда проект перезагружается, вы заметите, что Web.configs больше не "стекают" под "Web.config" . Это необходимо для того, чтобы "обмануть" TFS.

• Теперь скопируйте файл "Web.config" , вставьте его в один проект и переименуйте его в "Web.base.config" . Это будет использоваться для повторного генерации Web.config каждый раз (см. Следующий).

• Теперь выберите файл Web.config и перейдите в "File → Source Control → Exclude Web.config из Source Control". Кроме того, откройте "Проводник управления исходными текстами" (представление TFS Explorer) и найдите местоположение, где находится ваш Web.config, и удалите его из TFS. Это делается потому, что Web.config будет повторно генерироваться каждый раз, когда вы создадите проект (который я расскажу ниже).

• Теперь мы собираемся создать новый файл сборки, который поможет нам восстановить Web.config для любых построенных типов, даже для отладки (для чего не требуется преобразование Web.config Transformed). Создайте новый Xml файл в своем проекте и переименуйте его в "[YourProjectName].wpp.targets". Очень важно называть это именно тем, что называется вашим проектом, включая все точки, тире и т.д. (Например, My.Project.wpp.targets).

• Теперь введите следующий Xml в новый файл. Не беспокойтесь, если он начнет подчеркивать синтаксические ошибки:

  <?xml version="1.0" encoding="utf-8"?>
  <Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
      <UsingTask TaskName="TransformXml"
                 AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.Tasks.dll"/>
  
      <!-- Make sure web.config will be there even for package/publish -->
      <Target Name="CopyWebConfig" BeforeTargets="Build;Rebuild">
          <Copy SourceFiles="Web.base.config"
                DestinationFiles="Web.config"
                OverwriteReadOnlyFiles="true"
                SkipUnchangedFiles="false" />
      </Target>
  
      <Target Name="CustomTarget" BeforeTargets="BeforeBuild">
          <Message Text="Transforming: Web.$(Configuration).config" Importance="high" />
          <TransformXml Source="Web.base.config"
                        Transform="Web.$(Configuration).config"
                        Destination="Web.config" />
      </Target>
  </Project>
  

• Теперь, с этого момента, вы НИКОГДА, НИКОГДА не редактируете файл Web.config, он будет перезаписываться каждый раз, когда приложение компилируется. Вы редактируете только "Web.base.config" .

• Теперь сделаем проект похожим. Щелкните правой кнопкой мыши проект и "Разгрузите" его. Теперь щелкните правой кнопкой мыши и "Изменить". Теперь вернитесь назад и не комментируйте все элементы, которые мы прокомментировали на шаге №3. Кроме того, вы должны добавить элемент "DependentOn" в элементе "Web.base.config" , чтобы он также отображался в "Web.config" . Закройте и сохраните его, а затем снова загрузите проект. Вы должны заметить, что все конфиги теперь снова находятся под "Web.config" .

• На этом этапе вы можете добавить столько конфигураций в свой проект/решение, сколько захотите. Например, я добавил конфигурацию сборки под названием "Tim (Debug)", но конфигурация проекта называется "Tim.Debug". Когда я нажимаю правой кнопкой мыши на "Web.config" и выбираю "Add Config Transforms", теперь он добавляет мой файл "Web.Tim.Debug.config". Вы также можете добавлять конфигурации для среды или для каждой команды.

Стоит отметить, что ваши индивидуальные конфигурационные файлы являются только подмножеством "Web.base.config" , и они будут "преобразовываться" во время любого процесса сборки. Чтобы переключить трансформацию, которая будет построена во время отладки, просто перейдите к началу своего решения и выберите, какой Build Config вы хотите. Пока у вас есть web.config для этого Build Config, он преобразуется. Если нет, вы получите вместо этого "Web.base.config" .

ПРИМЕЧАНИЕ. Это также должно работать со стандартными приложениями Windows/WPF, а также с помощью "app.config".

Ответ 2

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

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

Например, меньшие различия между средами разработчиков уменьшают аргументы Works On My Machine (WOMM) и часто также уменьшают изменения конфигурации для сред за пределами разработки (например, Test, Production), что, в свою очередь, упрощает развертывание и уменьшает раздражающую конфигурацию среды -специфические ошибки.

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

Ответ 3

Джарретт,

Все, что у меня есть, - это анекдот о том, как мы справляемся с ситуацией.

У нас есть команда из 4-х программистов.

Мы используем решение управления источником вне VS - TortoiseSVN. Каждый из нас поддерживает наш собственный локальный web.config, который включен в проект. Файл проекта включен в репозиторий, но у нас есть параметр web.config для статуса "Игнорировать при фиксации".

Я не уверен, какой контроль над исходным кодом вы используете, но подрывная деятельность с Tortoise SVN (которая работает за пределами Visual Studio) отлично поработала для нашей небольшой команды. Большинство из нас программы на двух отдельных машинах... один в офисе, один на дому. Поэтому, когда вы связываете это с тем фактом, что у нас есть два производственных сервера, мы с комфортом имеем дело с 10 web.config для каждого проекта.

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

И последнее замечание: мы используем IIS 7 для отладки

Ответ 4

SO имеет хороший ответ для этого здесь. Я havent проверил несколько web.configs в VS2010, но мне интересно, добавлено ли это из-за изменений, которые они сделал make web.conig..

Ответ 5

Я использовал шаблоны T4 для решения этой проблемы. Вместо того, чтобы иметь web.config, у вас есть web.tt, который генерирует файл web.config. В файле web.tt вы можете создавать разные коды на основе имени машинного или текущего пользователя.