Bearbeiten

Freigeben über


Häufig gestellte Fragen für die Codeanalyse in Visual Studio

Diese Seite enthält Antworten auf einige häufig gestellte Fragen zur .NET Compiler Platform-basierten Codeanalyse in Visual Studio.

Codeanalyse im Vergleich zu EditorConfig

Sollte ich die Codeanalyse oder EditorConfig zum Überprüfen des Codeformats verwenden?

Die Codeanalyse- und EditorConfig-Dateien arbeiten Hand in Hand. Wenn Sie Codeformate in einer EditorConfig-Datei oder auf der Seite für Text-Editor-Optionen definieren, konfigurieren Sie tatsächlich die in Visual Studio integrierten Codeanalysetools. EditorConfig-Dateien können verwendet werden, um Analysetoolregeln zu aktivieren oder zu deaktivieren und um NuGet-Analysetoolpakete zu konfigurieren.

EditorConfig im Vergleich zu Regelsätzen

Sollten meine Analysetools mithilfe eines Regelsatzes oder einer EditorConfig-Datei konfiguriert werden?

Regelsätze und EditorConfig-Dateien können gleichzeitig vorhanden sein und zum Konfigurieren von Analysetools verwendet werden. Sowohl EditorConfig-Dateien als auch Regelsätze ermöglichen das Aktivieren und Deaktivieren von Regeln und das Festlegen deren Schweregrads.

EditorConfig-Dateien bieten jedoch weitere Möglichkeiten zum Konfigurieren von Regeln:

Zusätzlich zu Regelsätzen und EditorConfig-Dateien werden einige Analysetools durch die Verwendung von Textdateien konfiguriert, die als zusätzliche Dateien für die C#- und VB-Compiler gekennzeichnet sind.

Hinweis

  • EditorConfig-Dateien können nur zum Aktivieren von Regeln und Festlegen deren Schweregrads in Visual Studio 2019, Version 16.3 und höher verwendet werden.
  • EditorConfig-Dateien können nicht zum Konfigurieren der Legacyanalyse verwendet werden, wohingegen dies mit Regelsätzen möglich ist.

Codeanalyse in CI-Builds (Continuous Integration)

Funktioniert die .NET Compiler Platform-basierte Codeanalyse in CI-Builds (Continuous Integration)?

Ja. Bei Analysetools, die von einem NuGet-Paket installiert werden, werden diese Regeln zur Erstellungszeit (und während eines CI-Builds) erzwungen. Die in CI-Builds verwendeten Analysetools berücksichtigen die Regelkonfiguration für Regelsätze und EditorConfig-Dateien. Derzeit sind die in Visual Studio integrierten Codeanalysetools nicht als NuGet-Paket verfügbar, sodass diese Regeln in einem CI-Build nicht durchsetzbar sind.

IDE-Analysetools im Vergleich zu StyleCop

Worin besteht der Unterschied zwischen den IDE-Codeanalysetools in Visual Studio und StyleCop-Analysetools?

Die Visual Studio-IDE enthält integrierte Analysetools, die sowohl das Codeformat überprüfen als auch Qualitätsprobleme suchen. Diese Regeln helfen Ihnen, neue Sprachfeatures nach deren Einführung zu verwenden und die Verwaltbarkeit Ihres Codes zu verbessern. IDE-Analysetools werden ständig mit jeder Visual Studio-Version aktualisiert.

StyleCop-Analysetools sind Analysetools von Drittanbietern, die als NuGet-Paket installiert werden und die Formatkonsistenz in Ihrem Code überprüfen. Im Allgemeinen können Sie mit StyleCop-Regeln persönliche Einstellungen für eine Codebasis festlegen, ohne ein bestimmtes Format zu empfehlen.

Codeanalysetools im Vergleich zur Legacyanalyse

Worin besteht der Unterschied zwischen der Legacyanalyse und der .NET Compiler Platform-basierten Codeanalyse?

Die .NET Compiler Platform-basierte Codeanalyse analysiert den Quellcode in Echtzeit und während der Kompilierung, wohingegen die Legacyanalyse Binärdateien analysiert, nachdem der Build abgeschlossen wurde. Weitere Informationen finden Sie unter Quellcodeanalyse im Vergleich zur Legacyanalyse.

FxCop-Analysetools im Vergleich zu .NET-Analysetools

Was ist der Unterschied zwischen FxCop-Analysetools und .NET-Analysetools?

Sowohl FxCop-Analysetools als auch .NET-Analysetools beziehen sich auf die Implementierungen von FxCop-CA-Regeln der .NET Compiler Platform-Analysetools („Roslyn“). Vor Visual Studio 2019 (16.8) und .NET 5.0 wurden diese Analysetools als Microsoft.CodeAnalysis.FxCopAnalyzersNuGet-Paket bereitgestellt. Ab Visual Studio 2019 (16.8) und .NET 5.0 sind diese Analysetools im .NET SDK enthalten. Sie sind aber auch als Microsoft.CodeAnalysis.NetAnalyzersNuGet-Paket verfügbar. Erwägen Sie die Migration von FxCop-Analysetools zu .NET-Analysetools.

Warnungen als Fehler behandeln

Mein Projekt verwendet die Buildoption, um Warnungen als Fehler zu behandeln. Nach der Migration von der Legacyanalyse zur Quellcodeanalyse werden alle Codeanalysewarnungen nun als Fehler angezeigt. Wie kann ich dies verhindern?

Führen Sie die folgenden Schritte aus, um zu verhindern, dass Codeanalysewarnungen als Fehler behandelt werden:

  1. Erstellen Sie eine PROPS-Datei mit dem folgenden Inhalt:

    <Project>
       <PropertyGroup>
          <CodeAnalysisTreatWarningsAsErrors>false</CodeAnalysisTreatWarningsAsErrors>
       </PropertyGroup>
    </Project>
    
  2. Fügen Sie der CSPROJ- oder VBPROJ-Projektdatei eine Zeile hinzu, um die im vorherigen Schritt erstellte PROPS-Datei zu importieren. Diese Zeile muss vor allen Zeilen platziert werden, in denen die PROPS-Dateien des Analysetools importiert werden. Beispiel: Ihre PROPS-Datei wurde „codeanalysis.props“ genannt:

    ...
    <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')" />
    ...
    

Eigenschaftenseite der Codeanalyselösung

Wo befindet sich die Eigenschaftenseite der Codeanalyse für die Lösung?

Die Eigenschaftenseite der Codeanalyse auf Projektmappenebene wurde zugunsten der zuverlässigeren freigegebenen Eigenschaftengruppe entfernt. Für die Verwaltung der Codeanalyse auf Projektebene ist die Eigenschaftenseite der Codeanalyse weiterhin verfügbar. (Für verwaltete Projekte wird auch empfohlen, für die Regelkonfiguration von Regelsätzen zu EditorConfig zu migrieren.) Zum Freigeben von Regelsätzen für mehrere/alle Projekte in einer Projektmappe oder einem Repository wird empfohlen, eine Eigenschaftengruppe mit der CodeAnalysisRuleSet-Eigenschaft in einer freigegebenen PROPS/TARGETS-Datei oder directory.props/Directory.targets-Datei zu definieren. Wenn Sie keine gemeinsamen Eigenschaften oder Ziele besitzen, die alle Ihre Projekte importieren, sollten Sie darüber nachdenken, eine solche Eigenschaftengruppe zu einer Directory.props- oder Directory.targets-Datei in einem Projektmappenverzeichnis der obersten Ebene hinzuzufügen, das automatisch in alle Projektdateien importiert wird, die im Verzeichnis oder den zugehörigen Unterverzeichnissen definiert sind.