我在.net 4.7.1网络解决方案中有一个.net标准2.0类库。
在本地构建解决方案可以正常工作，但是当TFS服务器构建解决方案时，它无法编译.net 2.0标准库。它在编译过程中崩溃，并抱怨没有定义或导入system.object等。
它是运行旧的tfsbuild.proj样式xml文件的TFS 2015。 构建服务器是最新的.net 4.7.1，最新的.net核心2.0.3，最新的视觉工作室，最新的构建工具。
我可以看到它生成一个csc.exe命令来编译崩溃的.net标准2.0项目。如果我只是想运行＆＃34; dotnet build＆＃34;，那就很有效。
观察构建日志我可以看到在VS或＆＃34; dotnet build＆＃34;中运行时的CoreCompile步骤包含＆＃34;参考文献＆＃34;任务参数，引用.net标准2库。当构建服务器运行构建时，CoreCompile步骤中缺少此任务参数。
有没有人建议如何最好地在tfs服务器上获取msbuild以成功编译.net标准2.0项目？
我可以让msbuild生成必要的＆＃34;参考文献＆＃34;任务参数？
我最好选择关闭.net标准项目的自动构建，并尝试手动完成所有操作，并使用＆＃34; dotnet build＆＃34;相反，由于dotnet构建正确识别必要的引用？
答案 0 :(得分：3)
似乎您正在尝试使用VS2015 MSBuild工具来构建包含.NET Standard 2.0项目的解决方案。
.NET团队更改了项目文件结构（首次公布 here）用于新的.NET Core和.NET Standard项目 发布Visual Studio 2017。
TFS 2017 Update 2更新支持构建.NET Core / Standard。
.NET核心任务支持项目文件
使用当前更新，除了project.json之外，我们还在增强.NET核心任务以支持
*.csproj个文件。您现在可以使用Visual Studio 2017在您的构建代理上使用构建.NET核心应用程序 csproj文件。
作为一种解决方法，您可以尝试放弃使用TFS 2015构建任务MSBUILD和Visual Studio Build，现在使用命令行步骤。通常，如果您可以在命令行上执行任务，也可以在TFS / VSTS中执行该任务。更多详细步骤请参阅此博客：Building .NET Core and .NET Standard Projects in TFS 2015
答案 1 :(得分：0)
本周早些时候，我能够使用vNext构建系统获得一个针对netstandard2.0 + net452的类库，以便在TFS 2015更新4上构建。如果您能够运行PowerShell或批处理脚本，这可能会使用XAML构建。
@ PatrickLu-MSFT解释说，我必须做一些未提及的事情。
关键点/差异是
为TFS 2015安装更新2是不够的。您还需要在构建服务器上安装正确的VS组件。我不得不在构建服务器上安装/更新VS 2017 Enterprise 15.6.x 和 VS 2017 Build工具15.6.x.除了3.5和4.0之外，它们都具有所有目标包。 Dotnet核心是一个重要的选择，因为SDK项目支持似乎来自，并且您可能需要使用dotnet.exe。
运行dotnet restore而不是nuget.exe（4.5）或msbuild（v15.6）来恢复包。这两个人期望一些json文件并且不能为自己生成它。对我来说这是一个两行剧本;一个用于设置解决方案所在的位置，另一个用于调用还原。
之后，就像在PatrickLu的回答中提到的那样，调用与VS 2017一起安装的msbuild。
此时解决方案应该编译，但如果你需要在组件之后做其他事情，比如制作PDB或打包它，请注意这些潜在的问题......
nuget.exe pack并不了解如何找到正确制作nuget包的dll。它一直在寻找\release\any cpu\my.project\release\netstandard20\输出路径，但在该项目中没有定义。 \release\netstandard20 to release \ netstandard20 \ netstandard20`。/t:Pack添加到现有的msbuild调用失败，对于没有包目标的解决方案中的每个项目，例如正在打包的程序集的单元测试。