После обновления решения до.NET Framework 4.5 ежедневное развертывание перестало работать

Question

Мы с успехом ежедневно обновляем наш веб-сайт для разработчиков, используя msdeploy из TFS2010.

Это работало нормально, пока мы не обновили до VS2012, наше приложение с.NET Framework 4.0 до 4.5 и ASP.NET MVC с 3.0 до 4.0. Похоже, что все хорошо и сборки развернуты, но на самом деле ничего не было развернуто.

Я уже два дня занимаюсь этим и не могу понять, почему это происходит, и теперь у меня заканчиваются идеи.

Ниже приведена часть моего сценария сборки, как он работал до обновления.

<MSBuild
                Projects="$(SolutionRoot)\My.Web\My.Web.csproj"
                Properties="MvcBuildViews=False;AllowUntrustedCertificate=True;AuthType=Basic;Configuration=Dev;CreatePackageOnPublish=True;DeployIisAppPath=dev.myweb;DeployOnBuild=True;DeployTarget=MsDeployPublish;MSDeployPublishMethod=WMSvc;MsDeployServiceUrl=https://10.xxx.xxx.xxx:8172/MsDeploy.axd;UserName=UserName;Password=Password;UseMsdeployExe=True"
                ContinueOnError="False"
                />

Когда было начато обновление и обнаружена моя проблема, мы использовали Web Deploy 2.0, но теперь мы обновились до Web Deploy 3.0. Я также убедился, что мы строим с ToolsVersion="4.0",

ОБНОВИТЬ --

msbuild.exe / p: AllowUntrustedCertificate = True / p: AuthType = Basic / p: конфигурация =Dev /p:CreatePackageOnPublish=True /p:DeployIisAppPath=dev.myweb /p:DeployOnBuild=True /p:DeployTarget=MsDeployPublish MSDeployPublishMethod=WMSvc /p:MsDeployServiceUrl=https://10.xxx.xxx.xxx:8172/MsDeploy.axd /p:UserName=UserName /p: Пароль = Пароль /p:UseMsdeployExe=True E:\Builds\1 Какими бы ни были \Daily_Build\Sources\My.Web\My.Web.csproj

Теперь я также попытался запустить указанную выше команду msbuild из нашего TFS, но я не получил ответа, который полностью меня расстраивает. Ничего в журнале событий TFS, ничего в файле журнала, неважно многословия... Есть идеи?

Он работает с использованием msdeploy, как показано ниже;

<Exec Command="&quot;C:\Program Files\IIS\Microsoft Web Deploy V3\MSDeploy.exe&quot; -verb:sync -source:contentPath=&quot;E:\Builds\1\WhatEver\Daily_Build\Sources\My.Web\My.Web.csproj&quot; -dest:contentPath=&quot;E:\dev.my.web&quot;,computername=https://10.xxx.xxx.xxx:8172/MsDeploy.axd,username=UserName,password=Password,authtype=Basic -allowUntrusted=True"
              ContinueOnError="false" />

-

ОБНОВЛЕНИЕ 2 - Похоже, Microsoft добавила проверку того, какие проекты являются публикуемыми проектами, а наше веб-приложение - нет, поскольку Тип вывода - это Библиотека классов. Это было действительно с v4.0, но, очевидно, не для v4.5.

У кого-нибудь есть идея, что сделать, чтобы это снова заработало? Нужно ли менять тип проекта? Создать пакет публикации заранее, а затем развернуть это? Или что?

-

У кого-нибудь еще была такая же проблема? Вы нашли решение поделиться?

Может ли быть проблема с версией MSBuild?

Answer 1

Вот что я бы порекомендовал. В VS2012 мы упростили автоматизацию публикации ваших веб-проектов с помощью профилей публикации, которые создаются в диалоговом окне публикации. В вашем случае создайте новый профиль MSDeploy. Когда вы создаете этот профиль, мы сохраняем настройки в файл в папке Properties\PublishProfiles (или My Project\PublishProfiles для VB). Расширение этого файла будет.pubxml. Эти файлы на самом деле являются файлами MSBuild, которые вы можете настроить при необходимости. Вы также можете продолжать использовать диалог публикации. Пароль будет сохранен в файле.user и зашифрован так, что только вы сможете его расшифровать.

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

msbuild mysoln.sln /p:DeployOnBuild=true /p:PublishProfile=<ProfileName> /p:Password=<Password>

Если вы создаете.csproj/.vbproj, то вам нужно немного изменить это следующим образом

msbuild mysoln.sln /p:DeployOnBuild=true /p:PublishProfile=<ProfileName> /p:Password=<Password> /p:VisualStudioVersion=11.0

Подробнее о том, почему VisualStudioVersion требуется по адресу http://sedodream.com/2012/08/19/VisualStudioProjectCompatabilityAndVisualStudioVersion.aspx.

Как только вы это сделаете, вы сможете создавать + публиковать, как вы делали ранее. К вашему сведению, мы отправили все эти новые функции веб-публикации для VS2010 в Azure SDK https://www.windowsazure.com/en-us/develop/net/.

Также в вашем вопросе я заметил, что вы указываете некоторые пользовательские свойства, такие как MvcBuildViews. Теперь вы можете разместить эти свойства непосредственно в профиле публикации (файл.pubxml), если хотите. Конечно, вы все равно можете передать их в командной строке, если это имеет смысл для вашего сценария.

Более подробная информация об этом на http://sedodream.com/2012/06/15/VisualStudio2010WebPublishUpdates.aspx.

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

Answer 2

У меня была такая же проблема сегодня. Я тоже пытался автоматически развернуть веб-приложение.NET 4.5 на компьютере, на котором не установлена ​​Visual Studio 2012. Однако в моей ситуации было несколько незначительных отличий: я использовал TeamCity вместо TFS, и наше решение было создано с.NET 4.5, а не с обновлением с.NET 4.0.

Тем не менее, я описал ту же проблему. Я бы использовал MSBuild для создания веб-приложения и развертывания его в IIS, примерно так же. Этот подход отлично работал на моей машине разработчика. Однако, когда я запустил MSBuild на CI-сервере, он довольно успешно создал веб-приложение, но после этого остановился: никаких ошибок, никаких предупреждений, ничего, только сообщение об успешной сборке. Не было ни малейшего намека на попытку развертывания приложения в IIS.

Похоже, MSBuild не хватает соответствующих целей для выполнения веб-развертывания. Исправление было копировать папку C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web с моего компьютера разработчика на сервер CI, скопировав его в то же место на сервере CI, что и на моем компьютере.

Как только я это сделал, MSBuild ворчал о необходимости Web Deploy 3.0, но это было достаточно легко исправить. После установки этого на CI-сервер MSBuild также успешно развернул веб-приложение.

Answer 3

Чтобы расширить ответ Люка Вудворда:

Я тоже обнаружил, что развертывание C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\ с моей локальной машины на сервер сборки было исправление.

Однако реальное исправление заключается в установке Microsoft Web Developer Tools как части установки VS 2012, которая, помимо прочего, создаст эту папку. Это касается возражений Ieppie по поводу лицензирования.

Я проверил это...

1. Удаление C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\
2. Запуск установщика VS 2012 и добавление инструментов MS Web Dev.
3. Проверка того, что после установки C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\ вернулся.