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

Недавно мы обновили приложение VS 2010 и .NET 4 до VS 2012 и .NET 4.5. У нас есть сборка script для развертывания приложения на тестовом сервере. У нас есть две коробки: одна - Windows 8 с VS 2012 (новая версия), а другая - Windows 7 с VS 2010 и VS 2012 (установлена ​​недавно).

При запуске сборки script из окна Windows 8 сборка script работает хорошо и развертывает приложение для тестирования сервера. Но при развертывании приложения из окна Windows 7 появляется следующая ошибка:

"C:\Achinth\Build\Work\build\qa1sb.proj" (цель DeployAll) (1) → "C:\Achinth\Build\Work\App\App.csproj" (ResolveReferences; MsDeployPublish target) (2) → (MSDeployPublish target) → C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets(3847,5): ошибка: задача веб-развертывания ((8/19/2012 6:23:41 PM) Произошла ошибка при обработке запроса на удаленном компьютере.) [C:\Achinth\Build\Work\App\App.csproj] C:\Program Файлы (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets(3847,5): ошибка:\r [C:\Achinth\Build\Work\App\App.csproj] C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets(3847,5): error: (8/19/2012 6:23:41 PM) ошибка произошла, когда запрос был обработан на удаленном компьютере. \r [C:\Achinth\Build\Work\App\App.csproj] C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets(3847,5): ошибка: приложение po ol, который вы пытаетесь использовать, имеет свойство "managedRuntimeVersion", равное "v4.0". Для этого приложения требуется "v4.5". [C:\Achinth\Постройте\Work\App\App.csproj]

Глядя на ошибку, похоже, что MSBuild использует VS 2010 цели вместо VS 2012, что вызывает ошибку. Поскольку в окне Windows 8 нет VS 2010, он правильно использует VS 2012 цели.

Может ли кто-нибудь указать указатели на то, как заставить MSBuild выбрать правильную версию?

ОТВЕТЫ

Ответ 1

В этом случае вам нужно будет указать свойство MSBuild VisualStudioVersion = 11.0. Я просто писал об этом в http://sedodream.com/2012/08/19/VisualStudioProjectCompatabilityAndVisualStudioVersion.aspx, и я добавил его ниже для удобства.

Одной из наиболее востребованных функций Visual Studio 2012 была возможность открывать проекты как на VS 2012, так и на VS 2010 (требуется VS 2010 SP1). Если вы не слышали, что мы реализовали эту функцию. Возможно, вам интересно, как мы смогли это сделать и как это может повлиять на вас.

Если вы откроете файл .csproj/.vbproj для веб-проекта, созданного в VS2010, вы увидите следующий оператор импорта.

<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\
                  v10.0\WebApplications\Microsoft.WebApplication.targets" />

Когда вы открываете этот проект в VS 2012, в файл проекта внесены некоторые изменения, чтобы гарантировать, что он может быть открыт как в VS 2010 SP1, так и в VS 2012. Одно из изменений, внесенных в проект при его первой загрузке в VS 2012 добавить следующее, чтобы заменить этот оператор импорта.

<PropertyGroup>
  <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
  <VSToolsPath Condition="'$(VSToolsPath)' == ''">
    $(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />

Мы удалили жестко закодированную 10.0 и вместо этого использовали свойство VisualStudioVersion. При создании в Visual Studio 2012 это значение всегда будет 11.0, но для VS 2010 оно не существует. Вот почему мы по умолчанию поставили его на 10.0 выше. Существуют некоторые сценарии, в которых построение из командной строки потребует явно установить это свойство. Прежде, чем мы доберемся, позвольте мне объяснить, как это свойство устанавливается (в этом порядке)

  • Если VisualStudioVersion определяется как свойство среды/глобальное свойство MSBuild, которое используется.
    • Вот как команда командной строки VS и VS создала это значение
  • На основе версии файла .sln формата файла (используется набор инструментов - это формат sln файла -1)
    • Чтобы упростить этот оператор, файл .sln будет строить с указанием VisualStudioVersion на значение версии VS, которая создала файл .sln.
  • Выберите значение по умолчанию
    • 10.0, если установлен VS 2010
    • Установлена ​​версия с наивысшим версией подкомплектов.

Для # 2, когда вы создаете файл .sln, значение VisualStudioVersion будет -1 версии формата, найденной в файле .sln. Важно отметить, что если вы создадите файл .sln, он будет строить со значением VisualStudioVersion, соответствующим версии VS, которая создала файл .sln. Поэтому, если вы создаете файл .sln в VS2012, и вы всегда создаете этот .sln файл, значение для VisualStudioVersion будет 11.0. Во многих случаях, если вы создаете файл .sln, вы хороши.

Если вы создаете файлы .csproj/.vbproj без прохождения файла .sln? Если вы создаете веб-проект из командной строки (а не приглашение разработчика), то значение для используемого VisualStudioVersion будет 10.0. Это артефакт свойств, которые я показал выше. В этом случае вы должны передать это как свойство MSBuild. Например

msbuild.exe MyAwesomeWeb.csproj /p:VisualStudioVersion=11.0

В этом случае Im передает свойство явно. Это всегда будет переопределять любой другой механизм для определения значения для VisualStudioVersion. Если вы используете задачу MSBuild в сборке script, вы можете указать свойство либо в атрибуте "Свойства", либо в атрибуте "Дополнительные свойства". См. Предыдущее сообщение в блоге о разнице между свойствами и дополнительными свойствами.

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

Ответ 2

из этой ссылки.

"Откройте файл веб-проекта *.csproj или *.vbproj в текстовом редакторе и добавьте следующую строку.

<IgnoreDeployManagedRuntimeVersion>True</IgnoreDeployManagedRuntimeVersion>

Я добавил строку непосредственно перед строкой

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>

и он развертывается без ошибок. "

Это сработало для меня.

Ответ 3

Я заметил, что, когда я использую функцию VS2012 Publish Web Deploy Package, он создает .zip файл. Внутри этого zip есть файл с именем archive.xml, который содержит тэг createApp с атрибутом "managedRuntimeVersion =" v4.0 ". Когда я использую msdeploy.exe для синхронизации с экземпляром iis, он работает.

Однако, когда я использую msbuild.exe для создания файла .zip веб-пакета, он содержит файл archive.xml, который имеет "managedRuntimeVersion =" v4.5 ". Попытка развернуть этот веб-пакет в IIS с помощью файла msdeploy.exe приводит к ошибке ERROR_APPPOOL_VERSION_MISMATCH.

Как объяснил Ибрагим Хашими, добавив "/p:VisualStudioVersion=11.0" в мою командную строку msbuild.exe, эффективно принудительно "managedRuntimeVersion =" v4.0 "" в файле archive.xml результирующего веб-пакета, поэтому он разрешает проблема.

Ответ 4

Для тех, кто нашел эту страницу для поиска, почему msdeploy/webdeploy показывает аналогичную ошибку, я нашел это решением.

Чтобы устранить проблему, просто добавьте свойство DeployManagedRuntimeVersion в свой VS-проект:

<targetframeworkversion>v4.5</TargetFrameworkVersion></code>
<DeployManagedRuntimeVersion>v4.0</DeployManagedRuntimeVersion>

Отсюда: http://techblog.dorogin.com/2013/11/deploying-45-projects-with-webdeploy.html