Do MSBuild versions use different LangVersions when using <LangVersion>latest</LangVersion>?

[thecristidima]

I have a net6.0 console application with LangVersion set to latest. The code I am running is the one from this issue. My project also has the following global.json:

{
  "sdk": {
    "version": "6.0.100",
    "rollForward": "latestFeature"
  }
}

I noticed a strange behaviour when running my console application via command line and using Visual Studio 17.4.1. dotnet run will use MSBuild 17.0, while VS 17.4 uses MSBuild 17.4, which is perfectly normal.

The problem is that the code from the bug I linked will have a different output when the LangVersion is set to 10.0 compared to 11.0. When I run the build from 17.0 I get the output expected from C#10, but when I run the build from 17.4 I get the output expected from C#11.

I then added a build target to print $(NETCoreSDKVersion) and $(MaxSupportedLangVersion), but both builds print 6.0.111 and 10.0.

My question is if different MSBuild versions (in this case 17.0 and 17.4) will interpret <LangVersion>latest</LangVersion> differently, even though they display the same .NET SDK version and the same max supported language version, since I was expecting both of them to build the application as if latest == 10.0.

[rainersigwald]

Yes, sort of, for now.

This is an artifact of some details of how Visual Studio and the .NET SDK are each packaged and how they interact.

When have a global.json locking you to an SDK version and use .NET SDK (dotnet build/dotnet run) to build, every part of the build toolchain uses that version--you get the MSBuild that's packaged in that SDK, the SDK tasks and targets from that SDK, and the Roslyn tasks and targets from that SDK.

In Visual Studio/MSBuild.exe, it's not the same--you always get the MSBuild that is packaged with Visual Studio, import the SDK tasks and targets from the SDK mentioned in global.json, and get Roslyn tasks and targets from Visual Studio.

This can be quite confusing, and we're expecting to change this so that you always get a compiler that matches the SDK's in this situation--our tracking issue for that is #7832 (it will require changes in MSBuild, the SDK, and Roslyn, but that's a good place to follow along).

The best bet for now is probably to specify an explicit LangVersion, rather than latest.

cc @Forgind @jaredpar

[jaredpar]

Rather than "don't use LangVersion" I'd say "don't mix .NET SDK and VS Versions". If you always use the SDK version that comes with Visual Studio then there is no mismatch problem to worry about.