3

Due to a bug in the Roslyn compiler, I cannot build my project using v1.0 of the compiler (there is no workaround to make it work on 1.0). However, Microsoft has corrected the issue in a more recent version of the compiler.

When using Visual Studio, you can use a specific version of the compiler by adding the NuGet package available from https://www.nuget.org/packages/Microsoft.Net.Compilers/ to your project. This causes Visual Studio to use the specified version of the compiler when building the project.

However, when attempting to run a build on TeamCity, it does not seem to know to use the new version of the compiler. It only allows one to choose which version of Visual Studio to use. Is there any way to specify to TeamCity which version of the compiler to use manually?

Note: I am using TeamCity Professional 9.1.3 (build 37176) and in the build step I have chosen Visual Studio 2015.

When built locally, the build is done using:

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

But when built on TeamCity, the log shows:

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

I have also confirmed that the package is installed as part of the TeamCity build (prior to the csc command):

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

Is this just a symptom of how NuGet can behave differently in the Visual Studio UI vs. Command line? And if so, is there a workaround?

Update: I never did figure it out. Running the build in Visual Studio on the build server worked perfectly, but running the build using the exact same files through TeamCity did not work.

However, Microsoft released VS2015 Update 1, which resolves my original issue, though not this specific problem.

MineR
  • 2,144
  • 12
  • 18
  • When you run nuget from the command line, you are not installing a package, but restoring it. So the injected props file is already in the csproj. Could you try running msbuild from a TeamCity command line task? Maybe it is injecting some other properties by default. Also, could you post a verbose build output? You could also try to do an msbuild yourself on the build agent, and check if that picks up the correct csc version. – Tamas Nov 06 '15 at 05:50

1 Answers1

0

The Microsoft.Net.Compilers package is using the standard Nuget tooling. Specifically, there is a build folder in the package, which contains a props file. This props file gets injected into the csproj file, and is responsible for changing the csc executable to the one in the package.

If you are using msbuild 14, then the .props file is changing the CscToolPath, and the CscToolExe to point to the csc.exe in the package. So you just have to make sure that TeamCity is using msbuild 14.

Which version of TeamCity are you using? The documentation of 9.1 says that it supports msbuild 14 (msbuild 2015). If you are on older version, you could still use msbuild 14 from the command line runner.

Tamas
  • 6,260
  • 19
  • 30