Support file-scoped namespace declarations in generated .cs files

[DamianEdwards]

C# 10 introduces support for file-scoped namespace declarations and the .NET 6 templates are being updated to use this new syntax .

It would be great if the .cs files generated into the project by the EF tooling (dotnet ef) supported emitting namespaces using this new syntax. It could either:

• simply default to using the new syntax when the project targets .NET 6 (unless the project explicitly targets a lower version of C#)
• perhaps in addition sniff the content of .cs files in the project to determine which namespace declaration syntax the project is using and match that (e.g. match the first namespace declaration found in a .cs file with a depth-first search from project root)
• default to using the new syntax for .NET 6 targeted projects and support an option to opt-out of this behavior

[AndriySvyryd]

Spec: https://github.com/dotnet/csharplang/blob/main/proposals/csharp-10.0/file-scoped-namespaces.md

[bricelam]

Do we even care about older versions of C#? Typically, we've treated the default C# version of EF's minimum TFM as the minimum required version of C# in our tools.

[DamianEdwards]

What happens when I use dotnet ef 6.0 to add migrations to a project targeting .NET 5?

[bricelam]

You'll get code generated by version 5.0 of the Microsoft.EntityFrameworkCore.Design package

[bricelam]

(Assuming you're using EF Core 5 since EF Core 6 requires .NET 6)

[bricelam]

Note also that if you're using EF Core 3.1 on .NET 6, you'll get code generated by EF Core 3.1. The version of dotnet-ef is largely irreleveant.

[DamianEdwards]

Got it. That sounds great then. Are you suggesting then that perhaps migrations code should just be emitted using whatever language idioms we've decided are the most modern, and match what we've used in the project templates?

[bricelam]

Yep! See also #14545

[AraHaan]

I think another option is to do:

• add option --use-file-scoped for generating code from db (including the context)
• add option --global-using with the global usings the code normally adds on top of the generated code files to avoid them from being in the code files (but would require manually adding them with <Using Include="..." />).
• add option --internal to make all generated code internal instead of public.

Of which I get bitten by both bullets, I use global usings and file scoped namespaces.

[roji]

@AraHaan adding a switch for each and every possible code generation option isn't a good approach. Note that for EF Core 7.0, we plan to add templating support, which would allow scaffolded models to be tweaked exactly as you want them. We'll likely make the default template modern (e.g. using file-scoped namespaces), but users would be able to tweak the template to remove one feature or another.

[ErikEJ]

@AraHaan And there is Handlebars template support available today.

[DamianEdwards]

FYI there's early plans to have dotnet new auto-invoke dotnet format after project creation which will format code according to the users' editor.config preferences (including things like file-scoped namespaces). We should likely think about a complimentary approach for the files generated by EF Core.

[roji]

Our shiny new templates mechanism could somehow be aware of certain operation in .editorconfig and react accordingly?

[DamianEdwards]

@roji it would simply need to call dotnet format after generating any code, or we leave that as an exercise for the user and simply ensure the emitted code matches the defaults elsewhere (VS templates, etc.).

[bricelam]

Duplicate of #14545

[solrevdev]

This is a closed issue but EF Core is not respecting my project and generating the older style namespacing when generating a migration or is this going to be a .NET 7 thing.

Or is there anything I should be doing to make it work aka a command line flag etc.

Thanks all!

[ajcvickers]

@solrevdev This is covered by scaffolding templates in EF7. If you are using EF7, then you should get file-scoped namespaces by default, but can edit the templates to do something different.

[solrevdev]

@solrevdev This is covered by scaffolding templates in EF7. If you are using EF7, then you should get file-scoped namespaces by default, but can edit the templates to do something different.

Ahh an EF7 thing. I will upgrade once its ready (I read November 2022) so for now I'll just fix manually no problem. Thanks @ajcvickers so much for replying!

[solrevdev]

@solrevdev This is covered by scaffolding templates in EF7. If you are using EF7, then you should get file-scoped namespaces by default, but can edit the templates to do something different.

Hi @ajcvickers I think I may have misunderstood you because I've just upgraded my project to .NET 7 and EF Core 7 and dotnet ef migrations add is still outputting the block style namespaces and not respecting my preferred settings/.editorconfig for file scoped namespaces.

When I create a migrations it causes a/src/Core/Migrations/20221116131314_InitSchema.cs(9,1) error IDE0161: Convert to file-scoped namespace [/Users/solrevdev/Projects/projectname/src/Core/Core.csproj] error every time.

I dropped my database removed all migrations so that I was starting from creating a blank initial migration but that didn't help

So I still have to manually go in and change the migration by hand by either converting to file scoped or for speed I just add an // <auto-generated /> to the top of the file like the autogenerated designer files to prevent the error.

Am I missing something or doing something wrong? Do I need to edit a template or something?

I did read the scaffolding templates article you suggested but I am not generating my model from an existing database I am going code first plus I didn't see anything about file scoped namespaces in that document.

Any help would be appreciated as I've probably just ran out of talent!

Thanks
John

[AraHaan]

I feel like if you want to use file scoped namespaces that you must resort to doing database first. Besides I find using SSDT projects to be much easier to maintain than migrations (less files and less room for error and when there is a problem I can simply patch the sql file in the SSDT project then republish).

[roji]

@solrevdev EF7's templates covers database scaffolding (reverse engineering), not migration code. Modernizing migration C# code would be covered by #14545.

@AraHaan I definitely don't think that missing file-scoped namespace declarations is a good reason to abandon migrations or switch to database first.

[solrevdev]

@solrevdev EF7's templates covers database scaffolding (reverse engineering), not migration code. Modernizing migration C# code would be covered by #14545.

@AraHaan I definitely don't think that missing file-scoped namespace declarations is a good reason to abandon migrations or switch to database first.

Ahhh ok that makes sense! I’ll start watching the open issue #14545

Thanks for clearing that up for me much appreciated 🙏