Управление web.config для команд в VS2010 и TFS - PullRequest
20 голосов
/ 28 мая 2010

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

Раньше мы просто исключали web.config из нашего проекта, что позволяло бы каждому сохранять свою локальную версию web.config на своей машине. Мы перешли на VS2010, и теперь я вынужден добавить web.config в мой проект, чтобы запустить режим отладки. Поскольку наш проект связан с TFS, он автоматически добавляет web.config в систему управления версиями и пытается поддерживать его таким образом.

Есть ли способ запустить в режиме отладки без включения web.config в ваш проект? Или есть лучший способ управлять файлами конфигурации?

Ответы [ 5 ]

32 голосов
/ 28 января 2011

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

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

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

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

  2. Снова щелкните правой кнопкой мыши тот же веб-проект (теперь он должен быть выделен серым цветом) и выберите «Редактировать ... csproj». Это откроет проект в редакторе XML.

  3. Прокрутите вниз, пока не найдете раздел, содержащий все списки "Web.config". Теперь закомментируйте все элементы «DependentUpon» в Xml.

  4. Закройте редактор XML и сохраните изменения. Затем снова щелкните правой кнопкой мыши по вашему проекту и выберите «Перезагрузить». Когда проект перезагрузится, вы заметите, что Web.configs больше не «стекаются» под «Web.config». Это необходимо для того, чтобы «обмануть» TFS.

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

  6. Теперь выберите файл Web.config и перейдите в «Файл -> Управление исходным кодом -> Исключить Web.config из управления исходным кодом». Кроме того, откройте проводник управления исходным кодом (представление TFS Explorer), найдите расположение вашего Web.config и удалите его из TFS. Это сделано потому, что файл Web.config будет перегенерироваться каждый раз, когда вы создаете проект (о чем я расскажу далее).

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

  8. Теперь введите следующий 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>
    
  9. Теперь, с этого момента, вы НИКОГДА, НИКОГДА не редактируете Web.config, он будет перезаписываться при каждой компиляции приложения. Вы редактируете только "Web.base.config".

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

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


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

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

3 голосов
/ 22 сентября 2010

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

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

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

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

1 голос
/ 30 мая 2010

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

1 голос
/ 11 сентября 2010

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

1 голос
/ 30 мая 2010

Джарретт,

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

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

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

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

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

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

...