Как использовать преобразование конфигурации Visual Studio 2010 при локальном запуске / отладке? - PullRequest
Новая
       24

Как использовать преобразование конфигурации Visual Studio 2010 при локальном запуске / отладке?

6 голосов
/ 06 августа 2010

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

У нас есть несколько разных сред, которым нужны разные web.configs (строки подключения к базе данных, адреса WCF и т. Д.). Часто при отладке чего-либо высокого уровня, такого как веб-интерфейс, полезно настроить его для прямого соединения с бэкендом / базами данных TEST или QA. На локальном компьютере каждого разработчика IIS настраивается непосредственно в исходную папку каждого WCF / веб-проекта, а при локальном запуске достаточно просто отладить что-то с помощью Ctrl-Shift-B или F5. Можно было бы подумать, что было бы возможно собрать / F5 с TEST или QA в качестве режима конфигурации и получить конфигурацию TEST / QA, но я не понимаю, как это сделать. Это не поддерживается, или, может быть, нам нужно изменить то, как мы работаем с вещами?

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

1 Ответ

1 голос
/ 09 февраля 2011

Вы можете достичь желаемого эффекта, используя цели BeforeBuild и AfterBuild, доступные в файле .csproj. IDE VS.NET будет выполнять эти цели при выполнении Build или Rebuild, поэтому вы можете использовать их для выполнения преобразований web.config. Поскольку вам нужно выполнить преобразование web.config, а затем перезаписать реальный файл web.config, вам понадобится новый файл с именем web.default.config для хранения базовых данных web.config.

Я попробовал это в тестовом проекте, вот изменения, которые я внес в файл .csproj: 

<Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" />
<ProjectExtensions>
...
</ProjectExtensions>
<Target Name="BeforeBuild">
    <Copy SourceFiles="$(ProjectDir)web.default.config" DestinationFiles="$(ProjectDir)web.config" />
</Target>
<Target Name="AfterBuild" Condition="$(FirstRun) != 'false'">
    <MSBuild Projects="$(MSBuildProjectFile)" Targets="TransformWebConfig" Properties="FirstRun=false;" />
    <Sleep Milliseconds="2000" />
    <Copy SourceFiles="$(ProjectDir)obj\$(ConfigurationName)\TransformWebConfig\transformed\web.config"
        DestinationFiles="$(ProjectDir)web.config" />
</Target>

Мне пришлось вручную добавить их в файл .csproj (я использовал Notepad ++). Насколько я могу судить, нет возможности добавить эти инструкции через VSE. Вам необходимо предоставить условие для AfterBuild, чтобы избежать циклической ссылки, так как вызов MSBuild перезапустит сборку для генерации преобразования web.config.

В основном мы копируем файл web.default.config (наш базовый шаблон) поверх существующего файла web.config перед началом сборки, а затем мы используем MSBuild для создания файла web.config для любой конфигурации, которую мы строим. После завершения преобразования мы используем задачу «Копировать», чтобы взять преобразованный файл и скопировать его в файл web.config в корневом веб-каталоге. Одной из проблем, с которой я иногда сталкивался, была ошибка использования файла при попытке перезаписать файл web.config после завершения преобразования. Добавление задачи Sleep (из MSBuildCommunityTasks ) после того, как задача MSBuild решила эту проблему.

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

Идея FirstRun пришла из этой записи .

...