Unable to compile C# 7.1 code on VSTS build agents

[conficient]

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.

[conficient]

I noticed there is a GitHub project for agents at https://github.com/Microsoft/vsts-agent/issues - not sure if we should cross-post the issue there, or leave it here?

[jcouv]

Leave it here for now. I'm reached out to get contacts. I'll move the issue if needed.
Thanks

[conficient]

OK thanks

[jcouv]

@conficient, VSTS team confirmed that all of the public hosted machines have been updated with VS 15.3 and .NET Core 2.0.

This prompted me to read your repro in more details and it looks like the C# 7.1 compiler is indeed used, but it is using LangVersion 7.0.
If you project file is properly set with LangVersion 7.1, I do not yet know why the build would use 7.0. Can you double-check your project file?

One more way to troubleshoot this issue is to include a #error version pragma in your code (details) and submit it for build. The error you get back will confirm what LangVersion was passed to the compiler.

[conficient]

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!

[taspeotis]

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

[ewilansky]

Also confirmed this behavior in Visual Studio for Mac (version 7.2.2 (build 11). To fix it in this IDE:

• Right-click YourProject, click Options
• Click Build > General
• Change Language Options > C# Language Version to Version 7.1

[bojingo]

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.

[jcouv]

@bojingo There is an issue tracking this (LangVersion injected into project file by UI or API should not be configuration-specific): dotnet/project-system#2732
I do not know why it was that way in the first place.

[softlion]

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.

[bojingo]

"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

[paulohenriquesi]

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

[nickyzzi]

Wow, been struggling with this. My build server wasn't picking up 7.2 and I didn't realize I needed it for the release configuration. Thanks!

[paulohenriquesi]

The interface should update both configurations, the error is not clear and takes time to find out what's happening in the first time.

[Davilink]

@paulohenriquesi Thanks, i made the same mistake, now i will use the « All Configuration » for thing like that.

[vnextcoder]

How to fix this in DOTNETCore Project? I mean change the LangVersion

[jcouv]

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

[vdevappa]

This does not work if you just want to set it to latest. The solution is to provide the msbuild argument as shown here: https://stackoverflow.com/questions/48050676/how-do-i-set-csc-langversion-when-building-in-vsts

[taspeotis]

@vdevappa According the second comment to the answer (which links here), the problem was that LangVersion was only set for the debug configuration. See here for how to set LangVersion for all configurations.

[vdevappa]

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

[tswalker]

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.