Сбой развертывания MSBuild после обновления до.NET 4.5
Недавно мы обновили наше приложение VS 2010 и.NET 4 до VS 2012 и.NET 4.5. У нас есть скрипт сборки для развертывания приложения на тестовом сервере. У нас есть два блока: один - Windows 8 с VS 2012 (новая установка), а другой - Windows 7 с VS 2010 и VS 2012 (установлен заново).
При запуске скрипта сборки из Windows 8 окно сборки скрипта работает хорошо и развертывает приложение на тестовом сервере. Но при развертывании приложения из окна Windows 7 я получаю следующую ошибку:
"C: \ Achinth \ Build \ Work \ build \ qa1sb.proj" (цель DeployAll) (1) ->"C:\Achinth\Build\Work\App\App.csproj" (ResolveReferences; цель MsDeployPublish) (2) ->(цель MSDeployPublish) -> C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets(3847,5): ошибка: сбой задачи веб-развертывания. ((19.08.2012 18:23:41) Произошла ошибка при обработке запроса на удаленном компьютере.) [C:\Achinth\Build\Work\App\App.csproj]C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets(3847,5): ошибка: \r [C:\Achinth\Build\Work\App\App.csproj]C:\ Программные файлы (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ Web \ Microsoft.Web.Publishing.targets (3847,5): ошибка: (19.08.2012 18:23:41) Произошла ошибка, когда запрос был обработан на удаленном компьютере.\r [C:\Achinth\Build\Work\App\App.csproj]C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets(3847,5): ошибка: пул приложений t Если вы пытаетесь использовать, свойство 'managedRuntimeVersion' установлено в 'v4.0'. Это приложение требует "v4.5". [C:\Achinth\ Постройте \ Work \ App \ App.csproj]
Глядя на ошибку, похоже, что MSBuild использует цели VS 2010 вместо VS 2012, что вызывает ошибку. Поскольку в Windows 8 нет VS 2010, он правильно использует цели VS 2012.
Кто-нибудь может дать подсказки о том, как заставить MSBuild выбрать правильную версию?
5 ответов
В этом случае вам нужно будет указать свойство 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
В этом случае я передаю в собственность явно. Это всегда будет переопределять любой другой механизм, чтобы определить значение для VisualStudioVersion. Если вы используете задачу MSBuild в сценарии сборки, то вы можете указать это свойство либо в атрибуте Properties, либо в атрибуте AdditionalProperties. Смотрите мой предыдущий пост в блоге о разнице между свойствами и дополнительными свойствами.
Если при сборке / публикации вы столкнулись с каким-то странным поведением и заметили, что импортируются неправильные файлы.targets, вам может потребоваться указать это свойство.
По этой ссылке.
"Откройте файл веб-проекта *.csproj или *.vbproj в текстовом редакторе и добавьте следующую строку.
<IgnoreDeployManagedRuntimeVersion>True</IgnoreDeployManagedRuntimeVersion>
Я добавил строку прямо перед строкой
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
и разворачивается без ошибок ".
Это сработало для меня.
Я заметил, что когда я использую функцию 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 получившегося веб-пакета, что устраняет проблему.
Для тех, кто нашел эту страницу в поисках того, почему 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
В моем случае WebDeploy не был установлен на сервере сборки. Так что скинул подобную ошибку. Я установил WebDeploy, и я был золотой.
http://www.microsoft.com/en-ca/download/confirmation.aspx?id=25230