由于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（build 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，它解决了我的原始问题，但不是这个特定的问题。
答案 0 :(得分：0)
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。