Roslyn: Define spec for NuGet packages providing .editorconfig defaults

[jasonmalinowski]

There are some scenarios that exist where a NuGet package should be able to provide "default" .editorconfigs for a project. Consider the scenarios of:

1. A package like StyleCop wants to change the defaults to the "traditional" StyleCop defaults.
2. A company wants a package to specify their company-wide defaults that can be installed on all repos.

We need to design the following parts:

• [ ] The compiler switches needed to pass such a flag along.
• [ ] What the content is specified like in the NuGet package.
• [ ] How such a package, when installed, knows it's running on a version of the compiler that actually supports this.

For the latter, NuGet content support might be sufficient since we could define a new item group that it produces items for.

[jasonmalinowski]

(FYI to @sharwell)

[sharwell]

The semantics I'm considering would be the following:

• The .editorconfig files passed through this mechanism are evaluated without inheritance (it assumes without checking that root=true).
• For evaluating paths in the .editorconfig sections, only the filename is provided. In other words, the .editorconfig file is assumed to be located in the same directory as the source file, regardless of where the source file is.
• These files provide values for settings only in cases (at a per-property level) where the /editorconfig option (#18805) fails to provide a value.
  
  
  
  • The input is an ordered list of additional configuration files. The first file to provide a value is used.
  
  

Open questions:

• How is this embedded in a NuGet package?
• The order of inputs must be deterministic with respect to the set of sources of these additional files provided. But what is that order?

[jasonmalinowski]

Your last two questions are the ones that interest me most.

[sharwell]

@jasonmalinowski Are NuGet packages referenced by a project ordered when using <PackageReference>?

[jasonmalinowski]

MSBuild ItemGroups implicitly have an order. Whether that order is preserved through the tooling is definitely not something I'd bet a dollar on.

[AdamWillden]

In relation to what @sharwell proposed above:

The .editorconfig files passed through this mechanism are evaluated without inheritance (it assumes without checking that root=true).
For evaluating paths in the .editorconfig sections, only the filename is provided. In other words, the .editorconfig file is assumed to be located in the same directory as the source file, regardless of where the source file is.

I suggested something different in the proposed solution in #29592:

The issue lies in how the solution structure and physical folder structures combine to be interpreted for the purposes of inheritance. The easiest solution here is to only allow virtual files to be found at a project root. Then if a physical file also exists at the project root, the virtual file would take the role of the parent such that a project may override the distributed (virtual) version using a physical file.

As for the question:

How is this embedded in a NuGet package?

See this linked stylecop example also mentioned in #29592

[andersarpi]

Any update on this? Being able to centralize .editorconfig generation seems to be very sought-after by .net core developers.

[TheXenocide]

It seemed like we had some luck with including one in a NuGet package, but now I'm now sure if it's quite working consistently. That said, I have some thoughts on how this might work and be prioritized. Here's what I propose:

A new MSBuild ItemDefinition, EditorConfig, with Priority (for sorting the layering as it would if they were in different tiers of the hierarchical folder tree) and ConfiguredPath Metadata (for specifying directories deeper than the project file, or maybe for specifying configuration for source files included in the NuGet package). A NuGet package could package the file in their build/buildTransitive directory along with a props/targets file that Includes the EditConfig Item. I think by default an .editorconfig in the project directory or a configured path would apply last and override any settings supplied by a NuGet package; maybe this would be done by having the Microsoft.NET.Sdk glob **/.editorconfig with a very high Priority number? Perhaps something predictable so if someone wanted to make a package that overrides local settings it could? Perhaps other items would default to 0 and simply apply in the order they are processed. Here's a thought of what a Sample.Package.targets file would look like:

<Project>

  <PropertyGroup>
    <SamplePackageEditorConfigPriority Condition="'$(SamplePackageEditorConfigPriority)' == ''">0</SamplePackageEditorConfigPriority>
  </PropertyGroup>

  <ItemGroup>
    <EditorConfig Include="@(MSBuildThisFileDirectory)Sample.Package.editorconfig"> 
      <ConfiguredPath>$(MSBuildProjectDirectory)</ConfiguredPath>
      <Priority>$(SamplePackageEditorConfigPriority)</Priority>
    </EditorConfig>
  </ItemGroup>

</Project>

Thoughts?

[JimBobSquarePants]

I'm confused. I thought allowing a custom location was already allowed in VS 16.7?

https://twitter.com/davkean/status/1296314723512639490/

[AdamWillden]

I'm confused. I thought allowing a custom location was already allowed in VS 16.7?

https://twitter.com/davkean/status/1296314723512639490/

I wish they would document this stuff, least I missed it.

So, I have had a colleague try to do this. He says it definitely works for C# rules but not others. For instance we had a rule that states csproj files must use indent size 2. This apparently has no effect:

It's roslyn that enforces all the dotnet_ and csharp_ rules, the rest need to stay where they are for VS.

So it is a partial solution, meaning we can centralise the important stuff (so thank you for sharing) but I'd like to see it support all rules.

Also to note, we had issues with is_global so have ommitted this entirely in our setup.

[JimBobSquarePants]

I wish they would document this stuff, least I missed it.

I raised an issue against the docs for it a while back, hopefully it'll get added soon. https://github.com/MicrosoftDocs/visualstudio-docs/issues/6051

[julealgon]

While this is still under discussion, are there any known workarounds for sharing an .editorconfig file across multiple repositories without incurring the code duplication?

Should git submodules be considered for this in the meantime? Has anyone tried that?

I'm not a fan of creating a dependency between repositories like that, but I fail to see any other alternative at this point. Would be interested if anybody has come up with a different solution.