Design: Modernize generated C#

[bricelam]

This is related to #11744, but more general. We should investigate what the minimum version of C# we need to support in EF Core 3.0 is and modernize our generated code. I'm pretty sure there are a few expression bodied methods I'd like add...

[roji]

I think that with #10347 we'd be generating classes that use C# 8 nullability to express requiredness in properties... So I think C# 8 should be fine?

[ajcvickers]

Default is currently "8.0 (beta)"

[ajcvickers]

Consider:

• Reverse engineering to non-nullable types (strings).
• Can we do something based on project configuration?

[roji]

See nullability-related notes here: #10347 (comment)

[bricelam]

I think we can safely assume C# 8.0 as our language minimum version in EF Core 3.0. This is the default for projects targeting .NET Standard 2.1 and .NET Core 3.0.

[bricelam]

Areas I'd like to improve:

• Use nameof in data attributes RevEng: Use nameof in data annotations #11744
• Use auto-property initializers for collection properties
• Use nullable reference types when enabled Migration boilerplate causes "Nullable directive is redundant" if nullable types are disabled #31152
• Consider using AnnotationNames constants (not language-related, but they're public now)

[roji]

There's #15520 for tracking NRT scaffolding, should we close that and track everything there? Note that for NRTs specifically there's the additional opt-in flag so it's an additional thing to do.

[bricelam]

I think it goes beyond DbContext scaffolding too—model snapshots and migrations may also have to be updated when NRT is enabled in the project

[bricelam]

But maybe not as much as I think since NRT is more about member definitions than types...

[roji]

Yeah, could be...

[bricelam]

For example, will these work as-is in a project that enables NRTs?

DbContext

• protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
• protected override void OnModelCreating(ModelBuilder modelBuilder)

Migration

• protected override void Up(MigrationBuilder migrationBuilder)
• protected override void Down(MigrationBuilder migrationBuilder)
• protected override void BuildTargetModel(ModelBuilder modelBuilder)

ModelSnapshot

• protected override void BuildModel(ModelBuilder modelBuilder)

[Eli-Black-Work]

Would it make sense to reopen #25223? I feel like this issue is much broader than that one 🙂

[bricelam]

We like broad issues. We consider everything together when working on it. If, for whatever reason, it doesn't all fit into one release, we prioritize the important parts and file separate issues for any remaining items.

[Eli-Black-Work]

Okay 🙂

I'd like to post my request here, then, since I don't think it's been mentioned in this thread:

When EF Core starts modernizing its generated C# code, I'd love for it to respect our .editorconfig code-style settings.

For example, csharp_style_namespace_declarations = file_scoped/block_scoped should be respected 🙂

[DamianEdwards]

When EF Core starts modernizing its generated C# code, I'd love for it to respect our .editorconfig code-style settings.

There's been similar requests for ensuring code generated by templates does this too. In VS new files from templates are formatted according to current .editorconfig preferences. In the case of the CLI and tools like dotnet new we still need to figure out the mechanics of how this would work (i.e. discovering the Roslyn bits and loading/executing them, detecting dotnet format and running that, etc.).

[AraHaan]

Oh that should actually be relatively simple if roslyn was made into it's own shared framework (then it could use it without problems).

Pros:

• Any application that uses roslyn could roll forward if they use it as a shared framework.
• Visual Studio could use it as well.
• Source Generators and analyzers could use the shared framework as well (which could reduce restore times for large analyzers/generators) (Less downloads because the roslyn packages (would be stored in $DOTNET_ROOT/packs) and shared framework (would be stored in $DOTNET_ROOT/shared) would be cached on the user's machine).

Cons:

• Any applications that use apis that end up with breaking changes might break, if they set their application to roll forward on the frameworks.

[glen-84]

There's been similar requests for ensuring code generated by templates does this too.

This is probably dotnet/templating#5505.

[glen-84]

Can we drop the BOM 💣now as well?