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

jonathanpeppers · 2021-07-19T21:09:19Z

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

The text was updated successfully, but these errors were encountered:

dotnet-issue-labeler · 2021-07-19T21:09:22Z

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 · 2021-07-19T21:17:23Z

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?

Context: dotnet/sdk#19050 xamarin-android is hitting this build error with .NET 6 Preview 7: C:\src\xamarin-android\external\Java.Interop\src\Java.Interop\obj\Debug\net6.0\Java.Interop.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\xamarin-android\external\Java.Interop\src\Java.Interop\Java.Interop.csproj] In fact, you can reproduce this by doing: dotnet new console dotnet build -p:LangVersion=8.0 It seems like `@(Import)` item group should not be present unless the project is C# 10 or higher? For now, we can set `$(DisableImplicitNamespaceImports)` to workaround the issue.

davidfowl · 2021-07-20T06:24:13Z

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

jonathanpeppers · 2021-07-20T13:20:34Z

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 · 2021-07-21T17:22:02Z

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 · 2021-07-21T17:57:20Z

cc @jaredpar thoughts?

jaredpar · 2021-07-21T18:35:54Z

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 · 2021-07-22T13:23:58Z

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:/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.

Context: dotnet/sdk#19050 and dotnet/java-interop@4fb7c14

* Update dependencies from https:/xamarin/xamarin-android build 6.0.1xx-preview7-8ca289588b6969a2cc878afa0813afec8cd63dd3-1 Microsoft.Android.Sdk.Windows From Version 30.0.100-preview.7.91 -> To Version 30.0.100-preview.7.93 Dependency coherency updates Microsoft.NETCore.App.Ref,Microsoft.Dotnet.Sdk.Internal,Microsoft.Extensions.Primitives,Microsoft.AspNetCore.App.Runtime.win-x64,Microsoft.Extensions.Hosting.Abstractions,Microsoft.Extensions.DependencyInjection.Abstractions,Microsoft.Extensions.DependencyInjection,Microsoft.Extensions.Configuration.Abstractions,Microsoft.Extensions.Configuration,Microsoft.Extensions.Logging.Abstractions,Microsoft.Extensions.Logging,Microsoft.Extensions.Logging.Console,Microsoft.Extensions.Logging.Debug,Microsoft.Extensions.FileProviders.Abstractions,Microsoft.Extensions.FileProviders.Embedded,Microsoft.AspNetCore.Authorization,Microsoft.AspNetCore.Components.WebView,Microsoft.AspNetCore.Components.Web,Microsoft.JSInterop,Microsoft.WindowsDesktop.App.Runtime.win-x64,System.CodeDom From Version 6.0.0-preview.7.21326.8 -> To Version 6.0.0-preview.7.21368.2 (parent: Microsoft.Dotnet.Sdk.Internal * [build] remove workaround for iOS AOT packages on Windows * Ignore NU1703 in DeviceTests NU1703 warns about using nuget packages which have xamarin.ios tfm references from a newer net6.0-maccatalyst project. * Workaround error for implicit imports Context: dotnet/sdk#19050 and dotnet/java-interop@4fb7c14 * Ignore NU1703 for Mac Catalyst projects * Revert "Ignore NU1703 in DeviceTests" This reverts commit 8fdf5e1. * Revert "Revert "Ignore NU1703 in DeviceTests"" This reverts commit 4d0456d. * Fix other C# 10-related errors * Use `LangVersion=latest` by default * Fixed new NRT-related errors that appeared from C# 10.0 * Disable StaticWebAssets in MauiRazorClassLibrarySample Workaround to get the build to work. Will revert later to investigate. Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: Jonathan Peppers <[email protected]> Co-authored-by: Jonathan Dick <[email protected]> Co-authored-by: Eilon Lipton <[email protected]>

mattleibow · 2021-08-03T17:27:52Z

There is also a discussion here: #18825

dotMorten · 2021-08-11T15:10:26Z

I hit this today too. It's seems rather silly to turn on a feature that isn't supported.

jonathanpeppers · 2021-08-11T16:19:35Z

I think we can close this in favor of #19521, this feature is being redesigned.

The idea is you will have to opt into it with ImplicitUsings=true, so we wouldn't have hit an issue if that was the case.

Context: dotnet/sdk#19050 xamarin-android is hitting this build error with .NET 6 Preview 7: C:\src\xamarin-android\external\Java.Interop\src\Java.Interop\obj\Debug\net6.0\Java.Interop.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\xamarin-android\external\Java.Interop\src\Java.Interop\Java.Interop.csproj] In fact, you can reproduce this by doing: dotnet new console dotnet build -p:LangVersion=8.0 It seems like `@(Import)` item group should not be present unless the project is C# 10 or higher? For now, we can set `$(DisableImplicitNamespaceImports)` to workaround the issue.

dotnet-issue-labeler bot added the untriaged Request triage from a team member label Jul 19, 2021

jonathanpeppers mentioned this issue Jul 19, 2021

[build] set $(DisableImplicitNamespaceImports) by default dotnet/java-interop#859

Merged

JunTaoLuo added the Area-NetSDK label Jul 21, 2021

marcpopMSFT assigned wli3 Jul 21, 2021

Redth added a commit to dotnet/maui that referenced this issue Jul 22, 2021

Workaround error for implicit imports

cb7a820

Context: dotnet/sdk#19050 and dotnet/java-interop@4fb7c14

Redth added a commit to dotnet/maui that referenced this issue Jul 22, 2021

Workaround error for implicit imports

1a9b55c

Context: dotnet/sdk#19050 and dotnet/java-interop@4fb7c14

marcpopMSFT added the Area-ImplicitUsings label Aug 2, 2021

marcpopMSFT unassigned wli3 Aug 2, 2021

jonathanpeppers closed this as completed Aug 11, 2021

hkratz mentioned this issue Aug 16, 2021

Experimental support for osx-arm64 (Apple M1) hkratz/gha-runner-osx-arm64#2

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

jonathanpeppers commented Jul 19, 2021

dotnet-issue-labeler bot commented Jul 19, 2021

jonathanpeppers commented Jul 19, 2021

davidfowl commented Jul 20, 2021

jonathanpeppers commented Jul 20, 2021

JunTaoLuo commented Jul 21, 2021

davidfowl commented Jul 21, 2021

jaredpar commented Jul 21, 2021

jonathanpeppers commented Jul 22, 2021 •

edited

Loading

mattleibow commented Aug 3, 2021

dotMorten commented Aug 11, 2021

jonathanpeppers commented Aug 11, 2021

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

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

Comments

jonathanpeppers commented Jul 19, 2021

dotnet-issue-labeler bot commented Jul 19, 2021

jonathanpeppers commented Jul 19, 2021

davidfowl commented Jul 20, 2021

jonathanpeppers commented Jul 20, 2021

JunTaoLuo commented Jul 21, 2021

davidfowl commented Jul 21, 2021

jaredpar commented Jul 21, 2021

jonathanpeppers commented Jul 22, 2021 • edited Loading

mattleibow commented Aug 3, 2021

dotMorten commented Aug 11, 2021

jonathanpeppers commented Aug 11, 2021

jonathanpeppers commented Jul 22, 2021 •

edited

Loading