Em nossa organização, estamos executando vários repositórios GitHub com diferentes serviços da web. Todos esses projetos requerem regras comuns para estilo de código. Seguimos o caminho certo e criamos um projeto de modelo de serviço que é a base para todas as soluções .NET e define uma arquitetura comum. Contém um conjunto de projetos com nomenclatura e referências corretas. No entanto, movemos para o lado errado e copiamos o arquivo .editorconfig
para cada novo repositório. Houve uma tentação de modificar o arquivo .editorconfig
sempre que ele não atendesse às necessidades do desenvolvedor. E nós fizemos essa falha.
Não há muita informação na Internet sobre como criar um arquivo .editorconfig
comum e distribuí-lo em vários repositórios. O sentimento divino disse que deve ser um pacote NuGet. Depois de muito pesquisar o problema no Google, encontramos esta solução. Obrigado a Adam Craven , que resolveu o mesmo problema em seu projeto.
O EditorConfig ajuda a manter estilos de codificação consistentes para vários desenvolvedores que trabalham no mesmo projeto em vários editores e IDEs. O projeto EditorConfig consiste em um formato de arquivo para definir estilos de codificação e uma coleção de plug-ins de editor de texto que permitem aos editores ler o formato de arquivo e aderir aos estilos definidos. Os arquivos EditorConfig são facilmente legíveis e funcionam bem com sistemas de controle de versão.
No mundo .NET, as regras de análise de código têm várias opções de configuração. Você especifica essas opções como pares chave-valor em um dos seguintes arquivos de configuração do analisador:
Arquivo EditorConfig : opções de configuração baseadas em arquivo ou pasta.
Arquivo Global AnalyzerConfig : Opções de configuração em nível de projeto. Útil quando alguns arquivos de projeto residem fora da pasta do projeto.
Você pode definir a gravidade dos avisos do compilador ou das regras do analisador em um arquivo EditorConfig com a seguinte sintaxe:
dotnet_diagnostic.<rule ID>.severity = <severity>
Definir a gravidade de uma regra em um arquivo EditorConfig tem precedência sobre qualquer gravidade definida em um conjunto de regras ou no Solution Explorer.
Em alguns projetos, há uma mistura de arquivos de configuração locais e globais. Além disso, EditorConfg tem algumas limitações no mundo .NET também especificadas neste artigo na seção de limitações . Tentamos os dois caminhos e avançamos e recuamos com essas duas abordagens. E finalmente decidimos mover uma maneira simples de usar apenas o EditoConfig para nossos projetos.
Em primeiro lugar, você precisa criar um novo projeto de biblioteca C# para o pacote NuGet. Vamos chamá-lo de MyProject.EditorConfig
. Este projeto conterá os seguintes arquivos:
.props
.csproj
.editorconfig
Você precisa adicionar PropertyGroup com as seguintes propriedades definidas com o valor verdadeiro:
<PropertyGroup> <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild> <EnableNETAnalyzers>true</EnableNETAnalyzers> </PropertyGroup>
EnforceCodeStyleInBuild
- permite que regras de estilo de código especificadas no arquivo EditorConfig sejam verificadas como parte da construção;EnableNETAnalyzers
étrue por padrão para .NET 5.0 , mas defina-o como true para oferecer suporte a versões anteriores do .NET;
Uma das limitações do EditorConfig é que algumas regras possuem Location.None
e não podem ser especificadas em um arquivo EditorConfig. Se você não usar o arquivo Global AnalyzerConfig como nós, terá a opção de desabilitar essas regras no arquivo .props
:
<PropertyGroup> <NoWarn>$(NoWarn);CA1014</NoWarn> </PropertyGroup>
Especifique o local do arquivo .editorconfig
a ser copiado de dentro da estrutura de pastas do pacote NuGet:
<ItemGroup> <EditorConfigFilesToCopy Include="$(MSBuildThisFileDirectory)../content/Rules/.editorconfig" /> </ItemGroup>
Tenha cuidado com os símbolos
\
e/
na string do caminho do arquivo em diferentes plataformas. Levamos muito tempo para descobrir por que o arquivo.editorconfig
não é copiado.
Use a tarefa de Copy
do MSBuild para copiar o arquivo para a pasta do projeto .NET que está sendo criado. Este Target é definido para ser executado antes do MSBuild BeforeBuild
Target.
<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>
Por padrão, ao compactar os arquivos NuGet que começam com um ponto, eles são ignorados. Para evitar isso, você deve adicionar o seguinte código ao arquivo .csproj
:
<PropertyGroup> <NoDefaultExcludes>true</NoDefaultExcludes> </PropertyGroup>
Depois disso, você deve incluir os arquivos .props
e .editorconfig
:
<ItemGroup> <None Include="MyProject.EditorConfig.props" Pack="true" PackagePath="\build" /> <None Include=".editorconfig" Pack="true" PackagePath="\content\Rules" /> </ItemGroup>
Quando todo o trabalho estiver concluído, você poderá publicar o pacote NuGet no armazenamento local e verificar se ele funciona.
Execute o seguinte comando na pasta do projeto MyProject.EditorConfig
para compactar um pacote NuGet:
dotnet pack MyProject.EditorConfig.csproj -c Release -o out --no-restore
Publique-o no armazenamento local (pasta). O NuGet CLI deve ser instalado de antemão:
nuget add out/MyProject.EditorConfig.1.0.0.nupkg -Source /Users/igorlopushko/test_nuget_expand/ -Expand
Especifique uma pasta de destino com o parâmetro -Source
.
Registre o caminho do pacote NuGet local:
dotnet nuget add source /Users/igorlopushko/test_nuget_expand/
Para adicionar um pacote NuGet local ao projeto de destino, execute este comando na pasta do projeto de destino:
dotnet add package MyProject.EditorConfig -s /Users/igorlopushko/test_nuget_expand/
Ao construir seu projeto de destino, você obterá o arquivo .editorconfig
no diretório raiz deste projeto. Ele será substituído toda vez que você criar um projeto. Mesmo que tenha sido modificado de alguma forma por engano, o arquivo .editorconfig
será substituído na compilação.
A solução é bem simples, mas facilitou a vida da nossa equipe. Adicionamos este pacote NuGet a todos os nossos projetos e evitamos a dessincronização nos estilos de código em todos os repositórios.