Как создать пакет MSDeploy для приложения ASP.Net 5, предназначенного для .NET.

Я пытаюсь настроить Visual Studio Online на постоянное развертывание моего приложения ASPNET 5 на веб-приложение Azure, как описано в этом уроке из документов Team Foundation Build: https://msdn.microsoft.com/Library/vs/alm/Build/azure/deploy-aspnet5

Я следил за всеми шагами, и все работает отлично. По умолчанию этот script развертывает сборку моего приложения, которое нацелено на полный .Net 4.5.1 DNX, поэтому я решил попробовать его модифицировать для развертывания .Net Core.

Конструкция script создает свой пакет развертывания, вызывая: msbuild.exe /t:Build,FileSystemPublish После поворота многословия журнала и чтения через соответствующие файлы msbuild я узнал следующее:

Цель "Build" в конечном итоге использует dnx.exe для компиляции проекта. Поскольку файл project.json включает в себя как dnx451, так и coreclr TFM, этот шаг дает результат сборки для обеих фреймворков - пока это так хорошо.

Однако для цели FileSystemPublish, как представляется, выводится только пакет msdeploy, предназначенный для среды выполнения .NET 4.5.1. Из журналов я мог видеть, что выполнение цели FileSystemPublish в конечном итоге выдает команду "dnu publish", и в моих случаях передача "dnx-clr-win-x86.1.0.0-beta6" в качестве параметра -runtime. Когда я последовал за панировочными сухарями, чтобы узнать, откуда он получил значение "dnx-clr-win-x86.1.0.0-beta6", я в конечном итоге оказался в задаче "GetRuntimeToolingPath" в Microsoft.DNX.Tasks.dll. Эта задача, похоже, выглядит в global.json, чтобы определить правильное время выполнения для использования, но, как ни странно, внутренне переопределяет это значение с помощью "x86" и "clr" перед созданием строки возврата.

Если я правильно интерпретировал вещи, кажется, что цель FileSystemPublish (в Microsoft.DNX.Publishing.targets) по существу (косвенно) жестко связана с использованием x86, полной. DN инфраструктуры DNX при ее выпуске пакета. На этом этапе я зациклился на том, как получить этот процесс сборки для создания пакета .Net Core.

Мой вопрос заключается в том, почему FileSystemPublish будет связан с полным DNX файлом x86, и, учитывая, что это так (если я не ошибаюсь), что является рекомендуемым способом создания пакета msdeploy для приложения ASPNET 5, которое предназначено. Сетевое ядро?

EDIT: Пока у меня есть обходное решение. Я могу передать /p:RuntimeToolingDirectory="C:\Users\buildguest\.dnx\runtimes\dnx-coreclr-win-x64.1.0.0-beta6" в качестве параметра для msbuild. Это переопределяет логику по умолчанию в GetRuntimeToolPath и заставляет ее использовать .Net Core. Это работает, но выглядит как хак, поэтому я оставляю вопрос открытым для лучшего ответа.

Ответ 1

Чтобы опубликовать Core CLR, вы можете передать параметр msbuild 'PublishDNXVersion' как dnx-coreclr-win-x64.1.0.0-beta6.

msbuild <project>.xproj /p:deployOnBuild=true;PublishDNXVersion=dnx-coreclr-win-x64.1.0.0-beta6

Ответ 2

От портала "Старый лазурь" в разделе "Веб-приложение" его на странице "Панель мониторинга" вашего конкретного веб-приложения. [глубокий вдох]

С правой стороны находится раздел, в котором говорится, что "настроить публикацию с помощью визуальной студии онлайн". Нажав на эту ссылку, вы пройдете необходимые шаги, чтобы настроить непрерывное развертывание из онлайн-хранилища визуальной студии (либо на основе git, либо на основе tfs)

Так как это глоток, я предоставил ссылку на учебник, в котором вы просматриваете весь процесс: https://azure.microsoft.com/en-us/documentation/articles/cloud-services-continuous-delivery-use-vso/#step3

Ответ 3

Была та же проблема с инструментами .NET Core RC2-preview1. Мое решение: добавьте SDKToolingDirectory в мой .xproj с правильным путем установки .NET Core:

<PropertyGroup>
    <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">14.0</VisualStudioVersion>
    <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
    <SDKToolingDirectory>C:\Program Files\dotnet</SDKToolingDirectory>
</PropertyGroup>

Ответ 4

Мне повезло с этим, передав следующие параметры на этап Bundling моего процесса сборки Visual Studio Online:

/p:Bundle64BitRuntime=true /p:BundleCoreClrRuntime=true

Это приводит к тому, что моя публикация использует 64-битную рабочую среду CoreCLR, когда она запускается через msbuild.exe.

Я понял этот материал, пробив файл Microsoft.DNX.Publishing.targets(найденный в C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web) и ищет переменные, которые я мог бы перейти как свойства. Что касается времени выполнения, это, по-видимому, интересный фрагмент:

<GetRuntimeVersion 
  Condition="'$(IgnoreDNXRuntime)' != 'true'"
  RuntimeVersionOverride="$(PublishDNXVersion)"
  TargetDNXVersion="$(_DefaultDNXVersion)"
  RuntimeToolingVersion="$(RuntimeToolingVersion)"
  Want64Bit="$(Bundle64BitRuntime)"
  WantCoreClr="$(BundleCoreClrRuntime)">
  <Output PropertyName="FinalPublishVersion" TaskParameter="RuntimeVersion"></Output>
</GetRuntimeVersion>

Вероятно, здесь существует немного (?) риска с точки зрения будущей проверки вашей строковой процедуры против будущих изменений имен переменных. Но, вы знаете, бета-версия программного обеспечения и все такое:)

Удачи!