如何为面向.Net Core的ASP.Net 5应用程序构建MSDeploy包-Java 学习之路

我正在尝试配置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文件后，我学到了以下内容：

“Build”目标最终使用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耦合，并且考虑到这种情况（除非我弄错了）为ASPNet 5应用程序生成一个针对.Net核心的msdeploy软件包的推荐方法是什么？

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

4 回答

8

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

回复于 2024-04-27T00:34:24+08:00
0

从特定Web App的“仪表板”页面上的Web App部分中的旧Azure门户 . [深呼吸]

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

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

回复于 2024-04-27T00:34:24+08:00

与.NET Core RC2-preview1工具有同样的问题 . 我的解决方案：使用正确的.NET Core安装路径将 SDKToolingDirectory 添加到我的.xproj：

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

回复于 2024-04-27T00:34:24+08:00

2
通过将以下参数传递到Visual Studio Online构建过程的Bundling步骤，我有一些运气：
```
/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>
```
在将来证明您的构建例程与未来变量名称的更改方面，可能存在一点（？）风险 . 但是，你知道，测试版软件和所有:)

祝好运！
回复于 2024-04-27T00:34:24+08:00

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

4 回答

相关问题