[Epic] Common template features for .NET templates (sln, editorconfig)

[mikadumont]

Audience: template authors

Background

At the moment a lot of .NET project templates have to manually create similar configuration related to:

• framework
• restore post action
• optional adding of sln
• language-specific features
• nullable, global usings and other common MSBuild properties
• AOT configurations
• NuGet Packaging Properties (license, package name, authors, etc)

Moreover more common features will be nice to have:

• optional editorconfig (original intention of the issue)
• optional gitignore/gitattributes; git init

Implementing all of above is possible but will result in extra ~300 lines configuration in template.json and corresponding testing and maintenance effort. The configuration will be very similar to the same in all the templates.

Technical suggestion

We are considering to create a specific generator for .NET project templates which implicitly supports the features above.
All the author needs to do is to opt-in to desired behaviors via corresponding feature flags.

Justification

• facilitate much easier entry point for template authoring via simpler configuration
• decrease manual json configuration
• unify configuration for the items above
• unify experience with .NET SDK template

---

original description below
Copying Kathleen's comments from below:

The template team maintains the .NET standard .editorconfig. Logically this is the same one you get with dotnet new .editorconfig. Templates will not include .editorconfig.
When the user creates a project, they have the option to use --sln to create the project in a solution (a different feature that this assumes, although it might be later). If this switch is used, a .editorconfig will be placed at the solution level.
If the user either creates the new project with a parent directory that has a .sln file, or they use the --sln switch, no .editorconfig will be placed in the project file. Otherwise, it will be.
This might be managed by a post action so template authors could skip it, but we think it is probably the best behavior for all project templates.

The part about -sln is probably not relevant. Therefore, it should be considered out of the scope of this issue.

[DavidKarlas]

Can you share a bit more details what are you expecting here? Do you expect dotnet new editorconfig like #3195 suggests or you expect dotnet new console to include .editorconfig file?

[mikadumont]

Both but my issue is with regards to dotnet new console to include .editorconfig file (.NET) template which has the prepopulated default .NET code style, formatting, and naming conventions: https://docs.microsoft.com/en-us/visualstudio/ide/create-portable-custom-editor-options?view=vs-2019#add-an-editorconfig-file-to-a-project

[KathleenDollard]

@mikadumont @jmarolf and I chatted on this. It would be a nightmare to keep all the .editorconfig's consistent if we put them into every template, and then it would be a bad experience for users to wind up with multiple editor config's (per project) instead of one (per repo). That said, we love .editorconfig and want it in every repo :-) Thus, a new more complex feature!

A rough outline:

• The template team maintains the .NET standard .editorconfig. Logically this is the same one you get with dotnet new .editorconfig. Templates will not include .editorconfig.
• When the user creates a project, they have the option to use --sln to create the project in a solution (a different feature that this assumes, although it might be later). If this switch is used, a .editorconfig will be placed at the solution level.
• If the user either creates the new project with a parent directory that has a .sln file, or they use the --sln switch, no .editorconfig will be placed in the project file. Otherwise, it will be.
• This might be managed by a post action so template authors could skip it, but we think it is probably the best behavior for all project templates.

[terrajobst]

This sounds like another scenario where something like dotnet new repo would be useful…

[bekir-ozturk]

The details of the design can be found here (internal).