如何为面向 .Net Core 的 ASP.Net 5 应用程序构建 MSDeploy 包答案

【问题标题】：How to build an MSDeploy package for an ASP.Net 5 app that targets .Net Core如何为面向 .Net Core 的 ASP.Net 5 应用程序构建 MSDeploy 包
【发布时间】：2015-10-23 10:18:02
【问题描述】：

我正在尝试配置 Visual Studio Online 以将我的 ASPNET 5 应用程序持续部署到 Azure webapp，如 Team Foundation Build 文档中的本教程所述：https://msdn.microsoft.com/Library/vs/alm/Build/azure/deploy-aspnet5

我已按照所有步骤进行操作，一切正常。默认情况下，此脚本会部署针对完整 .Net 4.5.1 DNX 的应用构建，因此我决定尝试修改它以部署到 .Net Core。

构建脚本通过调用创建其部署包：msbuild.exe /t:Build,FileSystemPublish 在打开日志详细程度并阅读相关的 msbuild 文件后，我了解到以下内容：

“构建”目标最终使用 dnx.exe 来编译项目。因为 project.json 文件同时包含 dnx451 和 coreclr TFM，所以此步骤会为这两个框架生成构建输出 - 到目前为止一切都很好。

但是，FileSystemPublish 目标似乎只输出一个针对 .Net 4.5.1 运行时的 msdeploy 包。从日志中我可以看到执行 FileSystemPublish 目标最终会发出一个“dnu publish”命令，在我的情况下，将“dnx-clr-win-x86.1.0.0-beta6”作为 -runtime 参数传递。当我按照面包屑查找从哪里获取值“dnx-clr-win-x86.1.0.0-beta6”时，我最终在 Microsoft.DNX.Tasks.dll 中的“GetRuntimeToolingPath”任务中结束。此任务似乎在 global.json 中查找要使用的正确运行时，但奇怪的是在创建返回字符串之前在内部用“x86”和“clr”覆盖了这个值。

如果我的解释正确，似乎 FileSystemPublish 目标（在 Microsoft.DNX.Publishing.targets 中）本质上是（间接）硬连线以在生成其包输出时使用 x86、完整的 .Net 框架 DNX。在这一点上，我被困在如何让这个构建过程产生一个 .Net Core 包。

我的问题是，为什么 FileSystemPublish 会与 x86 完整的 .Net DNX 耦合，并且鉴于这种情况（除非我弄错了），为针对 .NET 的 ASPNET 5 应用程序生成 msdeploy 包的推荐方法是什么？网核？

编辑： 现在我有一个解决方法。我可以将/p:RuntimeToolingDirectory="C:\Users\buildguest\.dnx\runtimes\dnx-coreclr-win-x64.1.0.0-beta6" 作为参数传递给msbuild。这会覆盖 GetRuntimeToolPath 中的默认逻辑并强制它使用 .Net Core。这行得通，但感觉就像是 hack，所以我将问题留待获得更好的答案。

【问题讨论】：

你有想过这个吗？
我目前仍在使用我在编辑中描述的解决方法。到目前为止，我还没有找到更好的方法。

标签： msbuild asp.net-core packaging msdeploy azure-devops

【解决方案1】：

.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>

【讨论】：

【解决方案2】：

通过将以下参数传递到我的 Visual Studio Online 构建过程的捆绑步骤中，我很幸运：

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

这会导致我的发布在通过 msbuild.exe 运行时利用 64 位 CoreCLR 运行时。

我通过挖掘 Microsoft.DNX.Publishing.targets 文件（位于 C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web）并寻找我可以找到的变量来解决这个问题作为属性传入。关于运行时，这似乎是一个有趣的 sn-p：

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

在未来验证您的构建例程以应对未来对变量名称的更改方面，这里可能存在一点（？）风险。但是，你知道，测试版软件和所有这些:)

祝你好运！

【讨论】：

【解决方案3】：

要发布 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

【讨论】：

【解决方案4】：

从您特定 Web 应用的仪表板页面上的 Web 应用部分中的旧 Azure 门户。 [深呼吸]

右侧是“使用 Visual Studio Online 设置发布”部分。单击该链接将引导您完成从 Visual Studio 在线存储库（基于 git 或 tfs）设置持续部署的必要步骤

由于这很拗口，我提供了一个教程链接，该教程将引导您完成整个过程：https://azure.microsoft.com/en-us/documentation/articles/cloud-services-continuous-delivery-use-vso/#step3

【讨论】：

感谢您的回复大卫。不幸的是，您链接到的教程指的是以前版本的 ASP.Net（不使用 DNX），并且从 VSO 配置 CD 的说明使用旧的基于 XAML 的构建系统，而不是链接中提到的新系统 I假如。因此本教程与我的情况无关。