[EPIC] .NET 6 C# project templates use latest language idioms

[DamianEdwards]

In .NET 6, the included C# project templates will use the latest language idioms.

The following language features will be used or enabled by default in the SDK-included project templates as applicable:

• Top-level statements
• Global using directives (via SDK driven defaults)
• File-scoped namespaces (compiler tracking issue)
• Target-typed new expressions
• Nullable reference types
• async Main

Issues

• Console/Class lib project templates use latest C# language idioms #3360
• Test project templates use latest C# language idioms test-templates#164
• ASP.NET Core project templates use latest C# language idioms aspnetcore#33947
• Blazor project templates use latest C# language idioms aspnetcore#33948
• WinForms project templates use latest C# language idioms winforms#5171
• Import Windows Forms related props and targets into Windows Desktop wpf#4779
• WPF project templates use latest C# language idioms wpf#4774
• MAUI project templates use latest C# language idioms maui#1497
• Android project templates use latest C# language idioms android#6076
• iOS/Mac project templates use latest C# language idioms xamarin/xamarin-macios#12085
• Update scaffolders to support nullable reference types Scaffolding#1594
• Support file-scoped namespace declarations in generated .cs files efcore#25223

Area owners

Template area	Owner
Neutral (Console/Class lib)	@KathleenDollard
Unit testing	@kendrahavens
ASP.NET Core/gRPC/Worker	@DamianEdwards
Blazor	@danroth27
WinForms	@OliaG
WPF	@OliaG
MAUI	@mhutch

Implementation Considerations

• All changes detailed here will only be applied when the project is created targeting .NET 6+ (the default)
• Some templates have a --langVersion option and will need to condition the relevant changes based on the supplied value so that only compatible features are utilized in the new project
• Making the changes opt-in is not being considered at this time as it defeats the intended purpose which is to have the default experience for new projects reflect the latest language idioms
• ❓ Should all changes detailed here have corresponding template options to allow opting-out of them at project creation time?
  • ☑️ Decision on this is "No" for now. We can revisit based on feedback if necessary.

Top-level statements

• Language feature documentation
• Introduced in C# 9
• Project templates with an existing Program.cs will be updated to use top-level statements

Global using directives

• Language feature implementation issue
• Introduced in C# 10
• This feature is driven by SDK changes and as such no actual global using statements should appear in the template
• Existing using statements in project templates that conflict with new SDK-driven default global using directives will be removed
• The following namespaces are being globally included by the SDKs:
  • Microsoft.NET.SDK:
    • System
    • System.Collections.Generic
    • System.IO
    • System.Linq
    • System.Net.Http
    • System.Threading
    • System.Threading.Tasks
  • Microsoft.NET.SDK.Web:
    • Everything included by Microsoft.NET.SDK, plus:
    • System.Net.Http.Json
    • Microsoft.AspNetCore.Builder
    • Microsoft.AspNetCore.Hosting
    • Microsoft.AspNetCore.Http
    • Microsoft.AspNetCore.Routing
    • Microsoft.Extensions.Configuration
    • Microsoft.Extensions.DependencyInjection
    • Microsoft.Extensions.Hosting
    • Microsoft.Extensions.Logging
  • Microsoft.NET.SDK.Worker
    • Everything included by Microsoft.NET.SDK, plus:
    • Microsoft.Extensions.Configuration
    • Microsoft.Extensions.DependencyInjection
    • Microsoft.Extensions.Hosting
    • Microsoft.Extensions.Logging

File-scoped namespaces

• Language feature implementation issue
• Introduced in C# 10
• Any namespaces declared in existing project templates will be changed to use the file-scoped namespaces syntax
• ℹ️ This feature is not yet available in main builds but is expected to land during preview.7

Target-typed new expressions

• Language feature documentation
• Introduced in C# 9
• Any constructor invocation where the type name can be omitted to reduce its duplication
  • ✔️ private readonly static object s_syncObj = new object(); to private readonly static object s_syncObj = new();
  • ❌ var someStrings = new List<string>(); stays as it is now as the type name is not repeated

Nullable reference types

• Language feature documentation
• Introduced in C# 8
• Existing project templates will enable the feature by default by having <Nullable>enable</Nullable> added to their .csproj files
  • ℹ️ Enabling nullable reference types via SDK defaults was considered but rejected due to concerns with the experience during migration of existing projects to .NET 6, in that existing projects changed to target the .NET 6 TFM as part of migration will immediately exhibit compiler warnings associated with the feature being enabled and not handled correctly by the existing project code
• .cs, .cshtml, and .razor files in existing project templates will be updated to appropriately handle nullable reference types
• Code generation tools (e.g. Scaffolding, EF Core Migrations, etc.) should also be updated to ensure they produce code that is aligned with the nullable configuration of the target project.

async Main

• Language feature documentation
• Introduced in C# 7.1
• Project templates with an existing Program.cs containing a static void Main method declaration with a body that includes calls to Task-returning methods (or methods with a Task-returning alternative) will be updated to declare the method as async and the calls to Task-returning methods will be updated with the await keyword.

[danroth27]

To enable nullability checking in ASP.NET Core & Blazor there are a number of issues tracking related work:

• Nullable annotations support aspnetcore#27389
• Audit state of nullability support in ASP.NET Core aspnetcore#32783

Of particular concern is the impact of nullability checking on scaffolding and Razor.

[DamianEdwards]

@danroth27 anywhere we emit code into a project is indeed going to be problematic if it isn't taking nullability into account. The nullability in the framework APIs itself shouldn't cause issues AFAICT though right? With that in mind, we'll likely need to include updating scaffolding content within the scope of this effort, to ensure the code emitted appropriately handles nullables.

[maxkoshevoi]

Regarding using top-level statements by default.

My concern is that local methods don't support overloading and they look like regular methods when using top-level statements, which might confute people: dotnet/csharplang#3112 (comment)

Also with top-level statements you cannot use something like System.CommandLine.DragonFruit, but that's less of an issue then the first one.

[tthiery]

I know you are probably working already on tough timelines, but is this dotnet/templates#520 something worth considering. I added that issue after the community call asking for feedback and probably mixed up the template and templating repo ;).

[DorCoMaNdO]

Should all changes detailed here have corresponding template options to allow opting-out of them at project creation time?
Decision on this is "No" for now. We can revisit based on feedback if necessary.

These template changes do need opt-out options that don't involve "copy the old template and start from there" as the docs at https://aka.ms/new-console-template suggest.
Toggles on project creation wouldn't be a full solution as added classes will have no way to derive which template to use, given that this is mostly preference driven, code style options seem like the most logical choice.

I'll start with the disclaimer that I sadly cannot perform a full evaluation of these changes as my VS2022 installation appears to be broken (projects won't load at all within solutions, so other than the default Program.cs, Class1.cs or manually selected files opening without language features, I can't see how it all works in practice), but I do have strong feelings towards these changes.

I'm all in for new features such as async Main being used by default templates (at least the option to choose entry point type to save the couple of seconds it takes to rewrite the Main signature and reference System.Threading.Tasks), however, oversimplification by removing or changing using directives, namespace and class definitions by default with features such as "top-level statements" and "file-scoped namespaces" (as done for the Console and Library templates) for anyone other than beginners would likely be nothing but a cumbersome and potentially confusing change.
These changes DO affect readability, and I'd argue that's not for the better, these changes make it so you can no longer tell exactly what your program is doing at a glance without learning the implicit using directives and default entry point signature for your targeted runtime, which if changed in any future revision, can potentially affect the results of existing code based on the new template.

There's also the matter of code style consistency and preferences, as for consistency l fear this would be conflicting with existing projects and solutions that are upgraded to .NET 6 and new classes/projects are added (sadly I cannot test this at the moment), as for preferences, I (and others may) prefer explicit type definitions over var, for similar reasons I would prefer explicit using directives, I would also prefer the old style of namespace definitions given my brace and spacing preferences.

[nblumhardt]

Putting a global using for Microsoft.Extensions.Logging in the SDK, rather than in the templates, seems like it will create a lot of friction for people using Serilog (every use of ILogger became ambiguous after our own recent upgrade to .NET 6).

Little paper cuts like that (I have to know how to add a special property to a CSPROJ) are the kinds of things that could really erode the value in projects like Serilog over time. Any discussion open on this where I can catch up on the thinking so far?

[DamianEdwards]

@nblumhardt that's worth creating a specific issue to allow relevant discussion. Create one in the dotnet/sdk repo and tag me and we can chat about some potential mitigations.

[DamianEdwards]

Closing this as work in .NET 6 has been completed. A couple of items were pushed to post-6.0.