.NET 6 Preview 7 breaks builds that set $(LangVersion) 8.0

[jonathanpeppers]

Using 6.0.100-preview.7.21369.5, you can do:

dotnet new console
dotnet build -p:LangVersion=8.0 -bl

This fails with:

C:\src\globalusing\Program.cs(2,1): error CS8400: Feature 'top-level statements' is not available in C# 8.0. Please use language version 9.0 or greater. [C:\src\globalusing\globalusing.csproj]
C:\src\globalusing\obj\Debug\net6.0\globalusing.ImplicitNamespaceImports.cs(2,1): error CS8400: Feature 'global using directive' is not available in C# 8.0. Please use language version 10.0 or greater. [C:\src\globalusing\globalusing.csproj]
C:\src\globalusing\obj\Debug\net6.0\globalusing.ImplicitNamespaceImports.cs(3,1): error CS8400: Feature 'global using directive' is not available in C# 8.0. Please use language version 10.0 or greater. [C:\src\globalusing\globalusing.csproj]
C:\src\globalusing\obj\Debug\net6.0\globalusing.ImplicitNamespaceImports.cs(4,1): error CS8400: Feature 'global using directive' is not available in C# 8.0. Please use language version 10.0 or greater. [C:\src\globalusing\globalusing.csproj]
C:\src\globalusing\obj\Debug\net6.0\globalusing.ImplicitNamespaceImports.cs(5,1): error CS8400: Feature 'global using directive' is not available in C# 8.0. Please use language version 10.0 or greater. [C:\src\globalusing\globalusing.csproj]
C:\src\globalusing\obj\Debug\net6.0\globalusing.ImplicitNamespaceImports.cs(6,1): error CS8400: Feature 'global using directive' is not available in C# 8.0. Please use language version 10.0 or greater. [C:\src\globalusing\globalusing.csproj]
C:\src\globalusing\obj\Debug\net6.0\globalusing.ImplicitNamespaceImports.cs(7,1): error CS8400: Feature 'global using directive' is not available in C# 8.0. Please use language version 10.0 or greater. [C:\src\globalusing\globalusing.csproj]
C:\src\globalusing\obj\Debug\net6.0\globalusing.ImplicitNamespaceImports.cs(8,1): error CS8400: Feature 'global using directive' is not available in C# 8.0. Please use language version 10.0 or greater. [C:\src\globalusing\globalusing.csproj]

Binlog: msbuild.zip

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[jonathanpeppers]

The bigger issue here is the global using:

error CS8400: Feature 'global using directive' is not available in C# 8.0. Please use language version 10.0 or greater.

Ignore the top-level statement error:

error CS8400: Feature 'top-level statements' is not available in C# 8.0.

I think we shouldn't add to @(Import) item group unless it is C# 10 or higher?

[davidfowl]

You mean if the language version is explicitly set? Yes that's a good point @JunTaoLuo

[jonathanpeppers]

Our example in dotnet/java-interop#859 was a netstandard2.0 library that is sometimes built with Mono/MSBuild. It explicitly set $(LangVersion) to 8.0 so it could opt into NRT.

[JunTaoLuo]

I agree in principle. However, I want to highlight some nuances. LangVersion can be strings in additional to specific versions (e.g. preview, latest, latestMajor, etc) which can resolve to different C# version numbers. I don't think it's a good idea to duplicate the logic from Roslyn that deals with this resolution here in the SDK targets. Instead, it would be best if Roslyn can package that logic in a task that we can consume here.

Tactically, I think the most we could do is check if the version is a number version and if it is, disable this feature if it's below 10.0. Thoughts?

[davidfowl]

cc @jaredpar thoughts?

[jaredpar]

My thoughts here are that the customer has willingly downgraded one aspect of the project here (the language version). It is reasonable that they may need to downgrade other parts of the project here to compensate (implicit global usings)

Our general focus is that we default all of our experiences, including language version, based on the selected target framework. It's a very simple model for us to all follow. Particularly because all of our experiences have on "off" switch. That means the default experience is as vibrant as we want and customers have the knobs to disable experiences they don't want or aren't compatible with other knobs.

[jonathanpeppers]

I think it's quite reasonable to check $(LangVersion) here if it prevents breaks when updating to .NET 6.

When this change flowed to dotnet/maui we're seeing similar failures due to lots of LangVersion=9.0:

https://github.com/dotnet/maui/search?q=LangVersion

I don't actually know why they are there -- I just saw the break.

Tactically, I think the most we could do is check if the version is a number version and if it is, disable this feature if it's below 10.0. Thoughts?

@JunTaoLuo if $(LangVersion) is latest or default, I think everything in my example above works. So only an explicit version has an issue.