Подтвердить что ты не робот

MSBuild DeployOnBuild = true, не публикующий

У меня есть веб-приложение Visual Studio 2010 MVC2, которое я создаю через командную строку с помощью Hudson. Я бы хотел, чтобы Хадсон опубликовал веб-выход, поэтому я добавил теги DeployOnBuild = true и CreatePackageOnPublish = True в свою командную строку.

Моя команда:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe 
   /target:Clean,Build 
   /property:Configuration=Debug;DeployOnBuild=True;CreatePackageOnPublish=True; 
   [my project name.csproj]

Выполнение этой команды на моей машине разработки (Windows 7) успешно публикует веб-выход на \obj\Debug\Package\PackageTmp\. Но его запуск на сервере Hudson (WS 2008) успешно компилируется, но он не публикуется. Такая же команда, такая же версия MSBuild, тот же исходный код.

Я пробовал цель /t:Publish, которая дает мне ответ "Отказывать непубличный проект", как я видел на нескольких других сообщениях людей.

Я попытался добавить теги DeployOnBuild=True и CreatePackageOnPublish=True к моему файлу проекта, и никаких изменений не было.

Любые мысли о том, почему это не публикуется? Я неправильно использую эти теги? Я уверен, что что-то здесь, что я просто не вижу.

4b9b3361

ОТВЕТЫ

Ответ 1

Предполагая, что у вас не установлен Visual Studio 2010 на вашем hudson-сервере, возможно, вам не хватает файла публикации "Целевые". После большого количества головокружительных ударов я наконец решил это.

Некоторое время я знал, что мне нужно скопировать каталог

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications

с моей локальной машины с VS2010 на мой сервер, чтобы получить проект build. Но чтобы получить проект также опубликовать, мне также нужно было скопировать каталог

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web

Примечание. В моем случае я фактически передаю эти папки в свой исходный элемент управления и изменяю значение <MSBuildExtensionsPath32> в моем файле csproj, чтобы указать на эти выпадающие папки (так что при подготовке сервера требуется еще один шаг). Это не обязательно, чтобы заставить его работать, но вы можете подумать об этом после решения проблемы.

UPDATE: Итак, после того, как я сделал это, сборщик жаловался, что не смог найти "Microsoft.Web.Deployment.dll". Чтобы решить эту проблему, мне нужно было установить Microsoft Web Deploy v2.0 на сервер , хотя я публикую только в файловой системе. Думаю, я вижу в этом логику.

ОБНОВЛЕНИЕ: я обнаружил, что установка "Visual Studio 2010 Shell (Integrated)" через установщика веб-платформы IIS установит требуемые цели сборки. Это похоже на хороший компромисс между тем, что на вашем сервере не установлено все приложение Visual Studio, а не вручную копирует на ваш сервер произвольные папки на вашем компьютере.

Ответ 2

Кажется, что условия для запуска цели публикации не выполняются.

1) У вас могут быть разные пути публикации

2) Условие для запуска цели публикации ложно

Чтобы проверить, что оба из них вызывают команду с флагом /v: diag. Поиск Цель "Опубликовать" и попытаться выяснить, что на самом деле происходит. Он будет выглядеть как

Target "ExecuteT4Templates: (TargetId:144)" in file "D:\App\App.csproj" from project "D:\App\App.csproj":
Skipping target "ExecuteT4Templates" because all output files are up-to-date with respect to the input files.
Input files: D:\App\App.exe\\App_Config\Configuration.tt;D:\App\App.exe\\App_Config\Debug.App.tt;obj\\Debug.t4lastbuild
Output files: D:\App\App.exe\\App.config
Done building target "ExecuteT4Templates" in project "App.csproj".: (TargetId:144)

Ответ 3

Выполнял это с помощью VS2012 - закончил установку инструментов веб-разработчика на сервере сборки и исправил его.

Ответ 4

В дополнение к ответу Брайана Хинчи, я обнаружил, что мне также необходимо добавить мой пакетный вызов msbuild с дополнительным параметром VisualStudioVersion, чтобы правильная версия и путь к агенту сборки (TeamCity в моем случае) к Microsoft.WebApplication. цели будут вызваны. Без этого параметра шаг развертывания и публикации веб-страниц не был завершен, и моя партия завершилась успешно с возвратом кода 0, делая анализ очень сложным - даже с флагом /verbosity, добавленным к "отладке" сборки. Этот момент сделал SAYED IBRAHIM HASHIMI на своем сайте: http://sedodream.com/2012/08/19/VisualStudioProjectCompatabilityAndVisualStudioVersion.aspx

Сценарий для моего случая состоял в том, что у меня была совместимость с Visual Studio в моем веб-проекте MVC, чтобы я мог открыть проект в VS2010 или 2012 году (как указано в примечании выше) - так что я dev'ing локально в VS2012, тогда как агент сборки TeamCity имеет веб-сборку и развертывание целей VS 2010.