## The problem

In our organization, we are running multiple GitHub repositories with different web services. All these projects require common rules for code styling. We moved the right way and created a service template project which is a basis for all the .NET solutions and defines a common architecture. It contains a set of projects with correct naming and references. However, we moved the wrong way and copied the `.editorconfig` file to every new repository. There was a temptation to modify the `.editorconfig` file whenever it does not fit the developer’s needs. And we did this fault.

\
There is not much information on the Internet on how to create a common `.editorconfig` file and distribute it across multiple repositories. The god feeling told that it must be a NuGet package. After a long time of googling the problem, we found [this](https://devzone.channeladam.com/notebooks/languages/dotnet/editorconfig-distribution/) solution. Thanks to [Adam Craven](https://www.linkedin.com/in/adamcraven/) who solved the same issue for his project.

## Why EditorConfig

EditorConfig helps maintain consistent coding styles for multiple developers working on the same project across various editors and IDEs. The EditorConfig project consists of **a file format** for defining coding styles and a collection of **text editor plugins** that enable editors to read the file format and adhere to defined styles. EditorConfig files are easily readable and they work nicely with version control systems.

\
In the .NET world, code analysis rules have various configuration options. You specify these options as key-value pairs in one of the following analyzer configuration files:

* [EditorConfig](https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/configuration-files#editorconfig) file: File-based or folder-based configuration options.
* [Global AnalyzerConfig](https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/configuration-files#global-analyzerconfig) file: Project-level configuration options. Useful when some project files reside outside the project folder.

  \

You can set the severity for compiler warnings or analyzer rules in an EditorConfig file with the following syntax:

`dotnet_diagnostic.<rule ID>.severity = <severity>`

\
Setting a rule's [severity](https://docs.microsoft.com/en-us/visualstudio/code-quality/use-roslyn-analyzers?view=vs-2019#configure-severity-levels) in an EditorConfig file takes precedence over any severity that's set in a rule set or in Solution Explorer.

\
In some projects, there is a mix of local and global config files. Moreover, EditorConfg has some limitations in the .NET world also specified in this article in the [limitations](https://devzone.channeladam.com/notebooks/languages/dotnet/editorconfig-distribution) section. We tried both ways and moved back and forth with these two approaches. And finally decided to move a simple way to use just EditoConfig for our projects.

## The solution

First things first, you need to create a new C# library project for the NuGet package. Let’s call it `MyProject.EditorConfig`. This project will contain the following files:

* `.props` file
* `.csproj` file
* `.editorconfig` file

## .props file

You have to add PropertyGroup with the following properties set to the true value:

```csharp
<PropertyGroup>
  <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
  <EnableNETAnalyzers>true</EnableNETAnalyzers>
</PropertyGroup>
```

\
* `EnforceCodeStyleInBuild` - allows [code style rules](https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/overview#enable-on-build) specified in the EditorConfig file to be checked as part of the build;
* `EnableNETAnalyzers` is [true by default for .NET 5.0](https://docs.microsoft.com/en-us/dotnet/core/project-sdk/msbuild-props#enablenetanalyzers), but rather set it to true to support earlier versions of .NET;

\
As one of the limitations of EditorConfig is that some rules have `Location.None` and cannot be specified in an EditorConfig file. If you do not use the Global AnalyzerConfig file as we do, you would have an option to disable those rules in the `.props` file:

```csharp
<PropertyGroup>
  <NoWarn>$(NoWarn);CA1014</NoWarn>
</PropertyGroup>
```

\
Specify the location of the `.editorconfig` file to copy from within the NuGet package folder structure:

```csharp
<ItemGroup>
  <EditorConfigFilesToCopy Include="$(MSBuildThisFileDirectory)../content/Rules/.editorconfig" />
</ItemGroup>
```

\
> Be careful with `\` and `/` symbols in the file path string on different platforms. It really took us much time to figure out why `.editorconfig` file is not copied.

\
Use the MSBuild `Copy` Task to copy the file to the folder of the .NET Project that is being built. This Target is defined to execute before the MSBuild `BeforeBuild` Target.

```csharp
<Target Name="CopyEditorConfig" BeforeTargets="BeforeBuild">
  <Message Text="Copying the .editorconfig file from '@(EditorConfigFilesToCopy)' to '$(SolutionFolder)'"></Message>
  <Copy 
    SourceFiles="@(EditorConfigFilesToCopy)"
    DestinationFolder="$(SolutionFolder)"
    SkipUnchangedFiles="true"
    UseHardlinksIfPossible="false" />
</Target>
```

## .csproj file

By default, when packing NuGet files that start with a period are ignored. To avoid that you have to add the following code to the `.csproj` file:

```csharp
<PropertyGroup>
  <NoDefaultExcludes>true</NoDefaultExcludes>
</PropertyGroup>
```

\
After that you have to include `.props` and `.editorconfig` files:

```csharp
<ItemGroup>
  <None Include="MyProject.EditorConfig.props" Pack="true" PackagePath="\build" />
  <None Include=".editorconfig" Pack="true" PackagePath="\content\Rules" />
</ItemGroup>
```

## Build and test NuGet package

When the all job is done you can publish NuGet package to the local storage and verify that it works.

\
Execute the following command in the `MyProject.EditorConfig` project folder to pack a NuGet package:

```bash
dotnet pack MyProject.EditorConfig.csproj -c Release -o out --no-restore
```

\
Publish it into local storage (folder). [NuGet CLI](https://docs.microsoft.com/en-us/nuget/reference/nuget-exe-cli-reference) hast to be installed beforehand:

```bash
nuget add out/MyProject.EditorConfig.1.0.0.nupkg -Source /Users/igorlopushko/test_nuget_expand/ -Expand
```

Specify a target folder with `-Source` parameter.

 \n Register local NuGet package path:

```bash
dotnet nuget add source /Users/igorlopushko/test_nuget_expand/
```

\
To add a local NuGet package to the target project execute this command in the target project’s folder:

```bash
dotnet add package MyProject.EditorConfig -s /Users/igorlopushko/test_nuget_expand/
```

\
When you build your target project you will get the `.editorconfig` file in the root directory of this project. It will be overwritten every time you build a project. Even if it was modified somehow by mistake the `.editorconfig` file will be overwritten on the build.

## Conclusion

The solution is quite simple, but it made our team's life easier. We have added this NuGet package to all our projects and avoid desynchronization in code styles across all the repositories.

\
\
\


Microsoft

Target

2022 - HackerNoon Contributor of the Year - Dotnet

2022 - HackerNoon Contributor of the Year - Software Architecture

2022 - Software Developer of the Year

Coding Guru of 2022

Nominated for 2022 - HackerNoon Contributor of the Year - Dotnet

Nominated for Coding Guru of 2022

Nominated for 2022 - Software Developer of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Software Architecture

Too Long; Didn't Read

Cassandra Forward a free Cassandra-focused community event

How to Use Common EditorConfig as a NuGet Package

How to Use Common EditorConfig as a NuGet Package

Too Long; Didn't Read

Companies Mentioned

@igorlopushko

RELATED STORIES