如何在TFS2015上构建一个.NET Standard 2.0项目

Question

我有一个.net standard 2.0类库在一个.net 4.7.1 web解决方案中。

本地构建解决方案没有问题，但是当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 standard 2.0项目。如果我只运行“dotnet build”，它就能正常工作。

通过查看构建日志，我发现当在VS或“dotnet build”中运行CoreCompile步骤时，其中包含对.net standard 2库的“References”任务参数。但是，在构建服务器运行构建时，此任务参数在CoreCompile步骤中丢失。

有人有建议吗？如何才能使TFS服务器上的msbuild成功编译.net standard 2.0项目？

我能否让msbuild生成必要的“References”任务参数？

关闭自动构建.net standard项目并尝试使用“dotnet build”手动完成所有构建步骤是否是最佳选择，因为“dotnet build”能够正确识别必要的引用？

- Bub

---

你在TFS2015上使用哪个构建系统？是旧的XAML构建还是新的vNext构建？ - PatrickLu-MSFT

@DanielMann - 从TFS构建的起源到现在的每个版本都使用msbuild来构建.net项目。 - StingyJack

@StingyJack TFS 2008有一个构建系统，其中构建定义只是导入TFS特定目标（用于映射工作区和同步源代码等）的MSBuild文件。这就是我所指的。该问题涉及运行“tfsbuild.proj”文件，这是TFS 2008风格构建使用的约定。自TFS 2010引入XAML构建以来，该构建系统确实已被弃用，而XAML构建又在TFS 2015中引入了构建系统。 - Daniel Mann

我记得那种糟糕的感觉，但是对于 .net 的每个构建系统都将以 msbuild 为中心。 - StingyJack

Answer 1

看起来你正试图使用VS2015 MSBuild工具构建一个包含.NET Standard 2.0项目的解决方案。

.NET团队在Visual Studio 2017发布时宣布了 这里 针对新的.NET Core和.NET Standard项目进行了项目文件结构更改。

构建.NET Core/Standard的支持随着TFS 2017 Update 2更新而来。

.NET Core任务支持项目文件

通过当前更新，我们提升了.NET Core任务以支持*.csproj文件，除了project.json。现在你可以使用Visual Studio 2017在你的构建代理上使用csproj文件构建.NET Core应用程序。

作为一种解决方法，您可以尝试放弃使用 TFS 2015 构建任务 MSBUILD 和 Visual Studio Build，并现在使用命令行步骤。一般来说，如果您可以在命令行上执行任务，那么您也可以在 TFS/VSTS 上执行该任务。更详细的步骤请参考此博客：在 TFS 2015 中构建 .NET Core 和 .NET Standard 项目。

- PatrickLu-MSFT

---

我们正在运行一个旧的tfsbuild任务，而不是msbuild任务。 Visual Studio 2017无法打开我们的旧buildprocesstemplate进行编辑而不崩溃。很遗憾，从旧的tfsbuild.proj样式重写整个构建过程并不是我现在可以花时间去做的事情。我进行了一些测试，并注意到按照您建议的调用msbuild确实会起作用，但最终我选择手动调用dotnet build来作为构建步骤，因为远离tfs解决方案构建会引起我们许多其他问题。将此标记为答案。谢谢。 - Bub

Answer 2

本周早些时候，我成功地在 TFS 2015 更新 4 上使用 vNext 构建系统构建了一个针对 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文件，并且不能为自己生成它。对我来说，这是一个两行脚本；一个用于设置解决方案所在的位置，另一个用于调用还原操作。

之后只需调用与PatrickLu答案中提到的VS 2017安装的msbuild即可。

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

• nuget.exe pack无法正确找到DLL以正确制作NuGet包。它一直在寻找\release\any cpu\my.project\release\netstandard20\输出路径，但该项目中未定义此路径。
• VS 2017可能会尝试将输出路径从\release\netstandard20加倍到release\netstandard20\netstandard20`。
• 尝试将/t：Pack添加到现有的msbuild调用中失败，因为解决方案中每个没有打包目标的项目（例如要打包的程序集的单元测试）都会失败。
• MSFT docs pages中充满了通用信息，但缺少非SDK样式项目添加打包目标的方法。之前涵盖它们的版本已经不见了。
• netstandard2.0的默认“便携式”类型调试符号不能被内置的vnext构建任务索引。
• 在项目属性中选择所有配置的“full”调试符号类型不受msbuild的尊重。
• 向msbuild指定完整符号的命令行选项似乎可以生成可索引的符号，但我还没有尝试过它们是否可用。

- StingyJack