Perguntas frequentes sobre a análise de código no Visual Studio

Esta página contém respostas para algumas perguntas frequentes sobre a análise de código baseada no .NET Compiler Platform no Visual Studio.

Análise de código versus EditorConfig

Devo usar a análise de código ou o EditorConfig para verificar o estilo de código?

A análise de código e os arquivos EditorConfig funcionam lado a lado. Ao definir estilos de código em um arquivo EditorConfig ou na página Opções do editor de texto, você está realmente configurando os analisadores de código integrados ao Visual Studio. Os arquivos EditorConfig podem ser usados para habilitar ou desabilitar regras do analisador e também para configurar pacotes do analisador do NuGet.

EditorConfig versus conjuntos de regras

Devo configurar meus analisadores usando um conjunto de regras ou um arquivo EditorConfig?

Os conjuntos de regras e os arquivos EditorConfig podem coexistir e ambos podem ser usados para configurar analisadores. Os arquivos EditorConfig e os conjuntos de regras permitem habilitar e desabilitar regras e definir sua gravidade.

No entanto, os arquivos EditorConfig também oferecem maneiras adicionais de configurar regras:

Além dos conjuntos de regras e dos arquivos EditorConfig, alguns analisadores são configurados por meio do uso de arquivos de texto marcados como arquivos adicionais para os compiladores C# e VB.

Observação

  • Os arquivos EditorConfig só podem ser usados para habilitar regras e definir sua gravidade no Visual Studio 2019 versão 16.3 e posterior.
  • Os arquivos EditorConfig não podem ser usados para configurar a análise herdada, enquanto os conjuntos de regras podem.

Code Analysis em builds de integração contínua (CI)

A análise de código baseada no .NET Compiler Platform funciona em builds de CI (integração contínua)?

Sim. Para analisadores instalados a partir de um pacote NuGet, essas regras são impostas no tempo de build, inclusive durante um build de CI. Os analisadores usados em builds de CI respeitam a configuração de regras de conjuntos de regras e arquivos EditorConfig. Atualmente, os analisadores de código integrados ao Visual Studio não estão disponíveis como um pacote NuGet e, portanto, essas regras não são aplicáveis em um build de CI.

Analisadores de IDE versus StyleCop

Qual é a diferença entre os analisadores de código do IDE do Visual Studio e os analisadores StyleCop?

O IDE do Visual Studio inclui analisadores internos que procuram problemas de estilo de código e qualidade. Essas regras ajudam você a usar novos recursos de linguagem conforme eles são introduzidos e melhoram a capacidade de manutenção do seu código. Os analisadores de IDE são atualizados continuamente com cada versão do Visual Studio.

Os analisadores styleCop são analisadores de terceiros instalados como um pacote NuGet que verificam a consistência de estilo em seu código. Em geral, as regras StyleCop permitem definir preferências pessoais para uma base de código sem recomendar um estilo em vez de outro.

Analisadores de código versus análise herdada

Qual é a diferença entre a análise herdada e a análise de código baseada no .NET Compiler Platform?

A análise de código baseada no .NET Compiler Platform analisa o código-fonte em tempo real e durante a compilação, enquanto a análise herdada analisa arquivos binários após a conclusão do build. Para obter mais informações, confira Análise baseada no .NET Compiler Platform versus análise herdada.

Analisadores FxCop versus analisadores de .NET

Qual é a diferença entre o FxCop e os analisadores de .NET?

Os analisadores FxCop e analisadores de .NET referem-se às implementações do analisador de .NET Compiler Platform ("Roslyn") das regras de AC FxCop. Antes do Visual Studio 2019 16.8 e do .NET 5.0, esses analisadores eram enviados como um Microsoft.CodeAnalysis.FxCopAnalyzers pacote NuGet. Começando no Visual Studio 2019 16.8 e no .NET 5.0, esses analisadores são incluídos no SDK do .NET. Eles também estão disponíveis como Microsoft.CodeAnalysis.NetAnalyzers pacote NuGet. Considere migrar de analisadores FxCop para analisadores de .NET.

Tratar avisos como erros

Meu projeto usa a opção de build para tratar avisos como erros. Depois de migrar da análise herdada para a análise do código-fonte, todos os avisos de análise de código agora aparecem como erros. Como posso evitar isso?

Para impedir que avisos de análise de código sejam tratados como erros, siga estas etapas:

  1. Crie um arquivo .props com o seguinte conteúdo:

    <Project>
       <PropertyGroup>
          <CodeAnalysisTreatWarningsAsErrors>false</CodeAnalysisTreatWarningsAsErrors>
       </PropertyGroup>
    </Project>
    
  2. Adicione uma linha ao arquivo de projeto .csproj ou .vbproj para importar o arquivo .props criado na etapa anterior. Essa linha deve ser colocada antes de qualquer linha que importe os arquivos .props do analisador. Por exemplo, se o arquivo .props for chamado codeanalysis.props:

    ...
    <Import Project="..\..\codeanalysis.props" Condition="Exists('..\..\codeanalysis.props')" />
    <Import Project="..\packages\Microsoft.CodeAnalysis.NetAnalyzers.5.0.0\build\Microsoft.CodeAnalysis.NetAnalyzers.props" Condition="Exists('..\packages\Microsoft.CodeAnalysis.NetAnalyzers.5.0.0\build\Microsoft.CodeAnalysis.NetAnalyzers.props')" />
    ...
    

Página de propriedades da solução de análise de código

Onde está a página de propriedades do Code Analysis para a solução?

A página de propriedades do Code Analysis no nível da solução foi removida em favor do grupo de propriedades compartilhadas mais confiável. Para gerenciar o Code Analysis no nível do projeto, a página de propriedades do Code Analysis ainda está disponível. (Para projetos gerenciados, também recomendamos migrar do conjuntos de regras para o EditorConfig para configuração de regra.) Para compartilhar conjuntos de regras em vários/todos os projetos em uma solução ou um repositório, recomendamos definir um grupo de propriedades com a propriedade CodeAnalysisRuleSet em um arquivo de props/destinos compartilhado ou no arquivo Directory.props/Directory.targets. Se você não tiver props ou destinos comuns que todos os seus projetos importem, considere adicionar esse grupo de propriedades a um arquivo Directory.props ou Directory.targets em um diretório de solução de nível superior, que é importado automaticamente em todos os arquivos de projeto definidos no diretório ou em seus subdiretórios.