在 TeamCity 中使用特定的 Roslyn 编译器版本答案

【问题标题】：Use Specific Roslyn Compiler Version in TeamCity在 TeamCity 中使用特定的 Roslyn 编译器版本
【发布时间】：2015-11-05 03:30:53
【问题描述】：

由于 Roslyn 编译器中的错误，我无法使用编译器的 v1.0 构建我的项目（没有解决方法可以使其在 1.0 上运行）。但是，Microsoft 已在更新版本的编译器中更正了该问题。

使用 Visual Studio 时，您可以通过将https://www.nuget.org/packages/Microsoft.Net.Compilers/ 提供的 NuGet 包添加到您的项目来使用特定版本的编译器。这会导致 Visual Studio 在构建项目时使用指定版本的编译器。

但是，当尝试在 TeamCity 上运行构建时，它似乎不知道使用新版本的编译器。它只允许一个人选择使用哪个版本的 Visual Studio。有没有办法向 TeamCity 指定手动使用哪个版本的编译器？

注意：我使用的是 TeamCity Professional 9.1.3（内部版本 37176），并且在构建步骤中我选择了 Visual Studio 2015。

在本地构建时，使用以下命令完成构建：

D:\BitBucket\LocalPackages\Microsoft.Net.Compilers.1.1.0-beta1-20150928-02\build\..\tools\csc.exe /noconfig /nowarn:1701,1702,2008 ....

但在 TeamCity 上构建时，日志显示：

[Csc] C:\Program Files (x86)\MSBuild\14.0\bin\csc.exe /noconfig /nowarn:1701,1702 .....

我还确认该软件包是作为 TeamCity 构建的一部分安装的（在 csc 命令之前）：

[Exec] Installing 'Microsoft.Net.Compilers 1.1.0-beta1-20150928-02'.

这是否只是 NuGet 在 Visual Studio UI 与命令行中的行为方式不同的症状？如果是，是否有解决方法？

更新： 我从来没有弄明白。在构建服务器上的 Visual Studio 中运行构建运行良好，但通过 TeamCity 使用完全相同的文件运行构建却不起作用。

不过，微软发布了 VS2015 Update 1，它解决了我原来的问题，虽然不是这个特定的问题。

【问题讨论】：

当你从命令行运行 nuget 时，你不是在安装一个包，而是在恢复它。所以注入的 props 文件已经在 csproj 中了。您可以尝试从 TeamCity 命令行任务运行 msbuild 吗？也许它默认注入一些其他属性。另外，你能发布一个详细的构建输出吗？您也可以尝试自己在构建代理上进行 msbuild，并检查是否选择了正确的 csc 版本。

【解决方案1】：

Microsoft.Net.Compilers 包使用标准 Nuget 工具。具体来说，包中有一个build文件夹，里面有一个props文件。这个 props 文件被注入到 csproj 文件中，并负责将 csc 可执行文件更改为包中的可执行文件。

如果您使用的是 msbuild 14，那么 .props 文件将更改 CscToolPath 和 CscToolExe 以指向包中的 csc.exe。因此，您只需确保 TeamCity 使用的是 msbuild 14。

您使用的是哪个版本的 TeamCity？ 9.1 的文档说它支持 msbuild 14 (msbuild 2015)。如果您使用的是旧版本，您仍然可以从命令行运行程序使用 msbuild 14。

【讨论】：