Msbuild 如何为针对.NETCore的ASP.NET5应用程序构建MSDeploy包

我试图配置VisualStudio在线，将ASPNET 5的应用程序继续部署到Azure WebApp中，如本教程中从Team Foundation BudioDs:

中所描述的那样。 我遵循了所有的步骤，一切都很顺利。默认情况下，此脚本将部署一个针对完整.Net 4.5.1 DNX的应用程序版本，因此我决定尝试将其修改为针对.Net Core部署

生成脚本通过调用以下命令创建其部署包：

msbuild.exe/t:build，FileSystemPublish

在打开日志详细性并阅读相关msbuild文件后，我学到了以下内容：

“构建”目标最终使用dnx.exe编译项目。由于project.json文件同时包含dnx451和coreclr TFMs，因此此步骤为这两个框架生成生成输出—到目前为止效果良好

但是，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 framework DNX。在这一点上，我一直在思考如何让这个构建过程生成一个.Net核心包

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

编辑： 现在我有一个解决办法。我可以将

/p:RuntimeToolingDirectory=“C:\Users\buildguest\.dnx\runtimes\dnx-coreclr-win-x64.1.0.0-beta6”作为参数传递给msbuild。
这将覆盖GetRuntimeToolPath中的默认逻辑，并强制它使用.Net Core。这是可行的，但感觉像是一种黑客行为，所以我将保留这个问题，以获得更好的答案。
来自您特定Web应用的仪表板页面上Web应用部分的旧Azure门户。
[深呼吸]

右侧是一个部分，上面写着“使用visual studio online设置发布”。单击该链接将引导您完成从VisualStudio在线存储库（基于git或tfs）设置连续部署的必要步骤

由于这是一个很好的说明，我提供了一个教程的链接，该教程将引导您完成整个过程：
要发布核心CLR，可以将msbuild参数“PublishDNXVersion”作为dnx-coreclr-win-x64.1.0.0-beta6传递

msbuild.xproj/p:deployOnBuild=true；PublishDNXVersion=dnx-coreclr-win-x64.1.0.0-beta6
通过将以下参数传递到Visual Studio联机生成过程的绑定步骤，我获得了一些运气：

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

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

我通过挖掘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>



这里可能有一点风险（？）是为了防止您的构建例程将来更改变量名。但是，你知道，测试版软件和所有这些：）

祝你好运
 与.NET Core RC2-preview1工具有相同的问题。我的解决方案：将
SDKToolingDirectory
添加到My.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>


14
$（MSBuildExtensionsPath32）\Microsoft\VisualStudio\v$（VisualStudioVersion）
C:\ProgramFiles\dotnet
感谢您的回复，David。不幸的是，您链接到的教程引用了ASP.Net的早期版本（不使用DNX），从VSO配置CD的说明使用了旧的基于XAML的生成系统，而不是我提供的链接中提到的新系统。因此，本教程与我的情况无关。你有没有发现这一点？我目前仍在使用我在编辑中描述的解决方法。到目前为止，我还没有找到更好的方法。