CODEWITHSUNDEEP
visual-studiomsbuildvisual-studio-2019editorconfig
TheXenocide
TheXenocide

Reputation: 1149

Can Visual Studio use an .editorconfig not in the directory hierarchy?

We have a very large number of solutions spread across a wide number of repositories which do not always share a directory hierarchy in a way that makes it easy for us to update an .editorconfig such that it applies to all projects/solutions in the organization. We currently apply all of our code analysis configuration via an internal NuGet package and I was hoping we could include our organization-wide .editorconfig settings in this way as well?

I tried a quick experiment adding the following to a project to see if linked files would be honored (since we could simply add this to a props file we already have in the NuGet package), but it does not appear to be honored currently. 

  <ItemGroup>
    <None Include="C:\SomeAlternatePath\ECTest\.editorconfig" Link=".editorconfig" />
  </ItemGroup>

Is there some other MSBuild property or mechanism we could use to better facilitate this without literally writing a duplicate file to every solution/project/repo?

Upvotes: 3

Views: 6380

Answers (2)

Mike Nakis
Mike Nakis

Reputation: 61995

2022 Update:

Visual Studio cannot use an .editorconfig outside of the project hierarchy, but it does support some other ill-conceived, half-baked feature that Microsoft calls "Global AnalyzerConfig" a.k.a. "globalconfig".

These are configuration files whose syntax is very similar, but not quite identical, to editorconfig syntax, and can be explicitly included by your project as follows:

<ItemGroup>
  <!-- PEARL: if any .globalconfig files are not found, we get silent failure. -->
  <GlobalAnalyzerConfigFiles Include="../AllCode.globalconfig" />
  <GlobalAnalyzerConfigFiles Include="../ProductionCode.globalconfig" />
</ItemGroup>

Thus, you can give them any name you want, and place them anywhere you want.

They are ill-conceived and half-baked because:

According to official sources of information, you can use globalconfig for everything except IDE-only rules and options.

This means that you cannot use globalconfig for:

  • Tabs and spaces
  • Spell-checking
  • IDE0055 "Formatting rule" and all the options that apply to it.

So, globalconfig cannot fully replace editorconfig: you still need editorconfig files, but you can make them a lot smaller by moving all code analysis configuration to globalconfig.

Also:

You cannot have sections in globalconfig to apply different rules to different file types, nor can you assign different globalconfig files to different file types when including them from your project file, so you have to use them on a "one configuration fits all" basis.

Also:

The dotnet tooling treats syntax errors in globalconfig files with a policy of silent failure just as it does with editorconfig files. There are a meager few misuses of globalconfig syntax that they do report, unlike editorconfig, but it is nowhere near adequate, or acceptable, or abiding by any standard of decency.

Upvotes: 1

LoLance
LoLance

Reputation: 28146

Is there some other MSBuild property or mechanism we could use to better facilitate this without literally writing a duplicate file to every solution/project/repo?

I'm afraid the answer is negative. Cause the .editorconfig file have nothing to do with msbuild or xx.csproj. Only file hierarchy can affect the behavior how the config file works. More details please check this document.

Some tests:

When I right-click project=>add .editorconfig to add this file in current project, there's one line added to the xx.csproj: <None Include=".editorconfig"/>.

If we set the indent_size = 32, it works for current project. Now we can right-click that file=>Exclude from Project to remove that file from current project system. (This action will remove the <None Include=".editorconfig"/> in xx.csproj, but the file is still in the same folder where xx.csproj exists)

Now reload the project, the settings(indent_size=32) still works. So it's obvious if we place this file in project directory, then it will take effect, no matter if we have definitions about it in project file(xx.csproj).

Suggestions:

According to your description, all your projects use the same .editorconfig file. Since this file's working scope is affected by file hierarchy, you can reduce some meaningless work by:

1.Place that file in Solution folder, it will work for all projects under that solution folder

2.Place that file in repos(C:\Users\xxx\source\repos) folder, it will work for all solutions and projects under this folder.

3.So if most of your solutions are under path C:\somepath, place that file here, all projects under that path will benefit from that. And about precedence in file hierarchy please see this one.

Hope all above makes some help :)

Upvotes: 4

Related Questions