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


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

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

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

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

<MSBuild
                Projects="$(SolutionRoot)My.WebMy.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: CreatePackageOnPublish=True /p: DeployIisAppPath=dev.myweb /p: DeployOnBuild=True /p: DeployTarget=MsDeployPublish /p: MSDeployPublishMethod=WMSvc /p:MsDeployServiceUrl=https://10.ХХХ.ХХХ.ХХХ:8172/средства msdeploy.классов AXD /p: UserName=имя пользователя /p: Password=пароль /p: UseMsdeployExe=True E:Builds1WhatEverDaily_BuildSourcesMy.ВебМой.Сеть.csproj

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

Он работает с помощью msdeploy directy, как показано ниже;

<Exec Command="&quot;C:Program FilesIISMicrosoft Web Deploy V3MSDeploy.exe&quot; -verb:sync -source:contentPath=&quot;E:Builds1WhatEverDaily_BuildSourcesMy.WebMy.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?

3 6

3 ответа:

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

После того, как вы создали этот профиль, вы можете опубликовать его с помощью команды ниже, если вы создаете его .файл 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 в пакете SDK Azure https://www.windowsazure.com/en-us/develop/net/#.

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

Подробнее об этом на http://sedodream.com/2012/06/15/VisualStudio2010WebPublishUpdates.aspx .

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

Сегодня у меня была почти такая же проблема. Я тоже пытался получить веб-приложение .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 из моего dev компьютер на сервер CI, копируя его в то же место на сервере CI, что и на моей машине.

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

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

Я тоже обнаружил, что развертывание 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\ вернулся.