roslyn: Unable to compile C# 7.1 code on VSTS build agents

Visual Studio Enterprise 2017 v15.3.2 .NET framework 4.7.02046 VSTS Build Agent: 2.120.2 (running on Server 2008, latest patches)

Steps to Reproduce:

  1. Create c# console app for .NET 4.7
  2. Change void Main() to async Task Main()
  3. Change project to use C# 7.1
  4. Compile and run on dev machine
  5. Push repo to VSTS system
  6. Create a build: use “.NET Desktop” template
  7. Use local build queue
  8. Check “build solution” is set to “latest” Visual Studio version
  9. Save & Queue build

CSharp7_1_Test.zip

Expected Behavior:

Build completes and recognises async Task Main as valid C# 7.1

Actual Behavior:

Build fails with error:

2017-08-29T08:49:18.0026052Z ##[error]Program.cs(11,22): Error CS8107: Feature 'async main' is not available in C# 7. Please use language version 7.1 or greater.

Adding Roslyn compilers package does not fix this. Same error.

Notes:

First attempt on build server as 4.7 failed as the SDK was not installed (odd, since I’d installed VS 2017 on the machine earlier). Downloaded and ran NDP47-DevPack-KB3186612-ENU.exe on the build server to fix this.

Second build failed as expected (log below):

2017-08-29T08:48:44.2515948Z CoreCompile:
2017-08-29T08:48:44.2672205Z   E:\Microsoft Visual Studio 2017\Enterprise\MSBuild\15.0\Bin\Roslyn\csc.exe /noconfig /nowarn:1701,1702 /nostdlib+ /platform:anycpu32bitpreferred /errorreport:prompt /warn:4 /define:TRACE /highentropyva+ /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7\Microsoft.CSharp.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7\mscorlib.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7\System.Core.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7\System.Data.DataSetExtensions.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7\System.Data.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7\System.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7\System.Net.Http.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7\System.Xml.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7\System.Xml.Linq.dll" /debug:pdbonly /filealign:512 /optimize+ /out:obj\Release\CSharp7_1_Test.exe /ruleset:"E:\Microsoft Visual Studio 2017\Enterprise\Team Tools\Static Analysis Tools\\Rule Sets\MinimumRecommendedRules.ruleset" /subsystemversion:6.00 /target:exe /utf8output Program.cs Properties\AssemblyInfo.cs "D:\BuildAgent1\_work\_temp\.NETFramework,Version=v4.7.AssemblyAttributes.cs"
2017-08-29T08:48:45.2516396Z   Using shared compilation with compiler from directory: E:\Microsoft Visual Studio 2017\Enterprise\MSBuild\15.0\Bin\Roslyn
2017-08-29T08:49:18.0026052Z ##[error]Program.cs(11,22): Error CS8107: Feature 'async main' is not available in C# 7. Please use language version 7.1 or greater.
2017-08-29T08:49:18.0026052Z Program.cs(11,22): error CS8107: Feature 'async main' is not available in C# 7. Please use language version 7.1 or greater. [D:\BuildAgent1\_work\89\s\CSharp7_1_Test.csproj]
2017-08-29T08:49:18.0807322Z ##[error]CSC(0,0): Error CS5001: Program does not contain a static 'Main' method suitable for an entry point
2017-08-29T08:49:18.0807322Z CSC : error CS5001: Program does not contain a static 'Main' method suitable for an entry point [D:\BuildAgent1\_work\89\s\CSharp7_1_Test.csproj]
2017-08-29T08:49:18.1588592Z Done Building Project "D:\BuildAgent1\_work\89\s\CSharp7_1_Test.csproj" (default targets) -- FAILED.

[edit] I also tested by using the “Hosted VS2017” build agent queue - this failed with the same error.

Thanks to @jcouv for taking a look at this.

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Comments: 21 (4 by maintainers)

Most upvoted comments

I just checked and <LangVersion>7.1</LangVersion> was in the project file.

But as I did so I notice ( fx: forehead hitting desk ) it was in the debug property group. So it compiled okay locally (debug) but the build definition was release. Confirmed by adding the C# 7.1 to any CPU and release property groups and it compiles fine on Build Agent.

Sorry for the oversight!

I did this too, the easiest way to do it for all project configurations:

  • Right-click YourProject, click Properties

  • Click Build if it’s not already selected

  • Change Configuration to All Configurations

  • Click Advanced...

  • Change the language version

Why on earth is language version a build configuration-specific setting, anyway? For 99.9999 (few more nines)% of the cases you are compiling the same code for the different configurations, so why would we ever want different language features?

Pretty silly mistaken to be able to get caught on.

My problem was that, when I changed lang level via interface, it just update the debug build configuration in csproj, not the release.

In fact there is a real architecture bug which is not fixed:

  • create project A (netstandard), use a C#7.1 feature (like default) in its code. Set langage feature to “C# latest” (minor version) for both Debug and Release configs.
  • create project B (android) referencing project A
  • create a new build configuration only in projet B called “Staging”, copied from Release

Build on the command line configuration Release => works fine

Build on the command line configuration Staging => fails

Because the “Staging” configuration does not exist in project A, msbuild fails.

Either “C# latest” should be the default, or msbuild should know how to handle this situation better.

Still a problem with VS2017 15.9.24, which is suppose to support C#7.2 and it doesn’t by “default”

Some team members are using VS2019 which by “default” for language settings has NO XML verbose specifications for the solution, nor any projects in that solution. This is also true in VS2017.

If while using VS2019, and you have a public/private protected class defined… and you open this in VS2017, you get the “…is not available in C# 7. Please use language version 7.2 or greater”, which is should if every project has “default” enabled.

this works fine in VS2019, but not VS2017.

you cannot simply configure the “All Configurations > Advanced…” property for the language in VS2019, it simply will not allow you to do so. And in VS2017, you have to configure it specificaly for C#7.2, at EACH project level. It does not work at the solution level using Directory.Build.props (as stated here: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/configure-language-version ) to do it as a ‘global’ solution language specification… you still MUST do this at each individual project level.

so… the “default” in VS2017 is C#7.0 and nothing greater… to share the same code between VS2017 and VS2019, you either need to stick with C#7.0 convention (by not using the secured private protected method and just protected) or manual slap all that verbose XML into every single project. very irritating.

Yes and that does not work. Mine was already set similar to that.

@vnextcoder Here’s some information on setting the LangVersion in your project(s).

“C# latest” being the default can be problematic because as soon as a new version of C# comes out doesn’t mean all your build agents and such are immediately updated accordingly. The intent of the setting is to prevent people from using new features before they are ready for it. It just should be at the project level instead of specific build configuration level. (think of the settings in the project property pages that can’t be changed independently based on build configuration).

Then again…at least it would be a more predictable and intuitive error, so maybe that would be much preferred! 👍 @softlion