【问题标题】:How do I get a .net standard 2.0 project to build on TFS2015如何在 TFS2015 上构建 .net 标准 2.0 项目
【发布时间】:2018-04-30 05:06:59
【问题描述】:

我在 .net 4.7.1 Web 解决方案中有一个 .net 标准 2.0 类库。

在本地构建解决方案工作正常,但是当 TFS 服务器构建解决方案时,它无法编译 .net 2.0 标准库。它在编译期间崩溃并抱怨 system.object 等未定义或导入。

这是一个运行旧 tfsbuild.proj 样式 xml 文件的 TFS 2015。 构建服务器是最新的 .net 4.7.1、最新的 .net core 2.0.3、最新的 Visual Studio、最新的构建工具。

我可以看到它生成了一个 csc.exe 命令来编译崩溃的 .net 标准 2.0 项目。如果我只是运行“dotnet build”,效果很好。

查看构建日志,我可以看到在 VS 或“dotnet build”中运行时的 CoreCompile 步骤包含一个“引用”任务参数,其中引用了 .net 标准 2 库。构建服务器运行构建时,CoreCompile 步骤中缺少此任务参数。

有没有人建议如何最好地继续在 tfs 服务器上获取 msbuild 以成功编译 .net 标准 2.0 项目?

我可以让 msbuild 生成必要的“参考”任务参数吗?

我最好的选择是关闭 .net 标准项目的自动构建并尝试使用“dotnet build”作为构建步骤手动完成所有操作,因为 dotnet build 正确识别了必要的引用?

【问题讨论】:

  • 您在 TFS2015 上使用的是哪个构建系统?旧的 XAML 版本还是新的 vNext 版本?
  • @DanielMann - 从开始到当前构建的每个 TFS 版本都将 msbuild 用于 .net 项目。
  • @StingyJack TFS 2008 有一个构建系统,其中构建定义只是导入 TFS 特定目标的 MSBuild 文件(例如映射工作区和同步源代码)。这就是我所指的。该问题涉及运行 tfsbuild.proj 文件,这是 TFS 2008 样式构建使用的约定。自 TFS 2010 引入 XAML 构建以来,该构建系统确实已被弃用,而 XAML 构建又被 TFS 2015 中引入的构建系统弃用。
  • 我记得那很糟糕,但是 .net 的每个构建系统都将以 msbuild 为中心。

标签: tfs msbuild .net-standard-2.0


【解决方案1】:

本周早些时候,我能够使用 vNext 构建系统在 TFS 2015 更新 4 上构建一个面向 netstandard2.0+net452 的类库。如果您能够运行 PowerShell 或批处理脚本,这可能会使用 XAML 构建。

我必须做一些@PatrickLu-MSFT 解释中未提及的事情。

关键点/区别是

  1. 为 TFS 2015 安装更新 2 是不够的。您还需要在构建服务器上安装正确的 VS 组件。我必须在构建服务器上安装/更新 VS 2017 Enterprise 15.6.x VS 2017 Build tools 15.6.x。这两个都有除 3.5 和 4.0 之外的所有目标包。 dotnet core 是一个重要的选择,因为这似乎是 SDK 项目支持的来源,您可能需要使用 dotnet.exe。

  2. 运行 dotnet restore 而不是 nuget.exe (4.5) 或 msbuild (v15.6) 来恢复包。这两个人期望一些 JSON 文件并且不能自己生成它。对我来说,这是一个两行脚本;一个用于将位置设置为解决方案所在的位置,另一个用于调用还原。

之后就是调用与 VS 2017 一起安装的 msbuild,如 PatrickLu 的回答中所述。

此时解决方案应该可以编译,但如果您需要在此之后对程序集执行其他操作,例如制作 PDB 或打包它,请注意这些潜在问题...

  • nuget.exe pack 不明白如何找到 DLL 以正确制作 nuget 包。它一直在寻找 \release\any cpu\my.project\release\netstandard20\ 输出路径,但该项目中没有定义。
  • VS 2017 可能会尝试将您的输出路径从 \release\netstandard20 to release\netstandard20\netstandard20` 加倍。
  • 尝试将 /t:Pack 添加到现有的 msbuild 调用对于解决方案中没有打包目标的每个项目都会失败,例如正在打包的程序集的单元测试。
  • MSFT docs pages 充满了一般信息,但缺少如何为非 SDK 样式项目添加包目标。没有涵盖它们的先前版本。
  • netstandard2.0 的默认“便携式”类型调试符号无法被内置 vnext 构建任务索引。
  • msbuild 不支持在项目属性中为所有配置选择“完整”调试符号类型。
  • 为 msbuild 指定完整符号的命令行选项,确实可以生成可索引符号,但我没有尝试过它们是否有效。

【讨论】:

    【解决方案2】:

    您似乎正在尝试使用 VS2015 MSBuild 工具来构建包含 .NET Standard 2.0 项目的解决方案。

    .NET 团队更改了项目文件结构(首次公布 here) 用于新的 .NET Core 和 .NET Standard 项目以及 发布 Visual Studio 2017。

    TFS 2017 Update 2 更新支持构建 .NET Core/Standard。

    .NET Core 任务支持项目文件

    在当前更新中,我们正在增强 .NET 核心任务以支持除 project.json 之外的 *.csproj 文件。您现在可以使用视觉 Studio 2017 在您的构建代理上使用构建 .NET 核心应用程序 csproj 文件。

    作为一种解决方法,您可以尝试放弃使用 TFS 2015 构建任务 MSBUILD 和 Visual Studio Build,现在使用命令行步骤。一般来说,如果您可以在命令行上执行任务,您也可以在 TFS/VSTS 中执行。更详细的步骤请参考这篇博客:Building .NET Core and .NET Standard Projects in TFS 2015

    【讨论】:

    • 我们正在运行旧的 tfsbuild 任务,而不是 msbuild 任务。 Visual Studio 2017 不再能够打开我们旧的构建过程模板进行编辑而不会崩溃。不幸的是,从旧的 tfsbuild.proj 样式重写我们的整个构建过程并不是我现在可以花时间去做的事情。我做了一些测试,发现按照您的建议调用 msbuild 确实可以,但最后我选择在特定项目上手动调用 dotnet build 作为构建步骤,而不是因为远离 tfs 解决方案构建导致了很多其他问题或我们。将此标记为答案。泰。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2021-05-23
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-07-09
    • 2023-04-09
    • 2016-01-06
    相关资源
    最近更新 更多