Поделиться через


Часто задаваемые вопросы о анализе кода в Visual Studio

Эта страница содержит ответы на некоторые часто задаваемые вопросы о анализе кода на основе платформы компилятора .NET в Visual Studio.

Анализ кода и EditorConfig

Следует ли использовать анализ кода или EditorConfig для проверки стиля кода?

Анализ кода и файлы EditorConfig работают вручную. При определении стилей кода в файле EditorConfig или на странице параметров текстового редактора вы фактически настраиваете анализаторы кода, встроенные в Visual Studio. Файлы EditorConfig можно использовать для включения или отключения правил анализатора, а также для настройки пакетов анализаторов NuGet.

EditorConfig и наборы правил

Следует ли настроить анализаторы с помощью набора правил или файла EditorConfig?

Наборы правил и файлы EditorConfig могут сосуществовать и использовать для настройки анализаторов. Файлы EditorConfig и наборы правил позволяют включать и отключать правила и задавать их серьезность.

Однако в Visual Studio 2019 версии 16.5 и более поздних версиях файлы наборов правил устарели в пользу файлов EditorConfig, а проекты .NET Core и .NET 5+ не поддерживают все команды меню набора правил. Дополнительные сведения см. в разделе "Преобразование существующего файла набора правил" в файл EditorConfig.

Файлы EditorConfig предлагают дополнительные способы настройки правил:

Помимо наборов правил и файлов EditorConfig некоторые анализаторы настраиваются с помощью текстовых файлов, помеченных как дополнительные файлы для компиляторов C# и VB.

Замечание

  • Файлы EditorConfig можно использовать только для включения правил и задания их серьезности в Visual Studio 2019 версии 16.3 и более поздних версий.
  • Файлы EditorConfig нельзя использовать для настройки устаревшего анализа, а наборы правил могут.

Анализ кода в сборках непрерывной интеграции (CI)

Работает ли анализ кода на основе платформы компилятора .NET в сборках непрерывной интеграции (CI)?

Да. Для анализаторов, установленных с пакетом SDK для .NET версии 5.0 или более поздней версии, эти правила применяются во время сборки, в том числе во время сборки CI. Анализаторы, используемые в CI, учитывают конфигурацию правила как из наборов правил, так и файлов EditorConfig. Начиная с .NET 5.0 анализаторы стиля кода, встроенные в Visual Studio, также включены в пакет SDK для .NET, и большинство из них применяются в сборке CI. Дополнительные сведения см. в разделе "Включить в сборке".

Анализаторы интегрированной среды разработки и StyleCop

Какова разница между анализаторами кода интегрированной среды разработки Visual Studio и анализаторами StyleCop?

Интегрированная среда разработки Visual Studio включает встроенные анализаторы, которые ищут как стиль кода, так и проблемы с качеством. Эти правила помогают использовать новые языковые функции при их создании и повышении удобства обслуживания кода. Анализаторы интегрированной среды разработки постоянно обновляются с каждым выпуском Visual Studio.

Анализаторы StyleCop — это сторонние анализаторы, установленные как пакет NuGet, который проверяет согласованность стиля в коде. Как правило, правила StyleCop позволяют задавать личные настройки для базы кода, не рекомендовать один стиль для другого.

Анализаторы кода и устаревший анализ

Какова разница между устаревшим анализом и анализом кода на основе платформы компилятора .NET?

Анализ кода на основе платформы компилятора .NET анализирует исходный код в режиме реального времени и во время компиляции, в то время как устаревший анализ анализирует двоичные файлы после завершения сборки. Дополнительные сведения см. в статье об анализе платформы компилятора .NET и устаревшем анализе.

Анализаторы FxCop и анализаторы .NET

Какова разница между анализаторами FxCop и анализаторами .NET?

Анализаторы FxCop и анализаторы .NET относятся к реализации правил ЦС FxCop для платформы компилятора .NET (Roslyn). До Visual Studio 2019 16.8 и .NET 5.0 эти анализаторы поставляются как Microsoft.CodeAnalysis.FxCopAnalyzersпакет NuGet. Начиная с Visual Studio 2019 16.8 и .NET 5.0, эти анализаторы включены в пакет SDK для .NET. Они также доступны в виде Microsoft.CodeAnalysis.NetAnalyzersпакета NuGet. Рекомендуется перенести анализаторы FxCop в анализаторы .NET.

Обрабатывать предупреждения как ошибки

Мой проект использует параметр сборки для обработки предупреждений как ошибок. После миграции из устаревшего анализа в анализ исходного кода все предупреждения об анализе кода теперь отображаются как ошибки. Как предотвратить это?

Чтобы предотвратить обработку предупреждений анализа кода как ошибок, выполните следующие действия.

  1. Создайте props-файл со следующим содержимым:

    <Project>
       <PropertyGroup>
          <CodeAnalysisTreatWarningsAsErrors>false</CodeAnalysisTreatWarningsAsErrors>
       </PropertyGroup>
    </Project>
    
  2. Добавьте строку в файл проекта CSPROJ или VBPROJ, чтобы импортировать файл PROPS, созданный на предыдущем шаге. Эта строка должна быть помещена перед любыми строками, импортируемыми файлами props анализатора. Например, если props-файл называется 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')" />
    ...
    

Страница свойств решения анализа кода

Где находится страница свойств Анализа кода для решения?

Страница свойств Анализа кода на уровне решения была удалена в пользу более надежной группы общих свойств. Для управления анализом кода на уровне проекта страница свойств анализа кода по-прежнему доступна. (Для управляемых проектов также рекомендуется перенести из наборов правил в EditorConfig для конфигурации правила.) Для совместного использования наборов правил для нескольких проектов в решении или репозитории рекомендуется определить группу свойств с свойством CodeAnalysisRuleSet в общем файле props/targets или файле Directory.props/Directory.targets . Если у вас нет таких общих реквизитов или целевых объектов, которые импортируются во всех проектах, следует добавить такую группу свойств в файл Directory.props или Directory.targets в каталог решения верхнего уровня, который автоматически импортируется во всех файлах проекта, определенных в каталоге или его вложенных каталогах.