Diese Seite enthält Antworten auf einige häufig gestellte Fragen zur .NET-Compilerplattform-basierten Codeanalyse in Visual Studio.
Codeanalyse im Vergleich zu EditorConfig
Sollte ich codeanalyse oder EditorConfig zum Überprüfen des Codestils verwenden?
Codeanalyse und EditorConfig-Dateien funktionieren hand in Hand. Wenn Sie Codeformatvorlagen in einer EditorConfig-Datei oder auf der Seite "Optionen" des Text-Editors definieren, konfigurieren Sie tatsächlich die codeanalysatoren, die in Visual Studio integriert sind. EditorConfig-Dateien können zum Aktivieren oder Deaktivieren von Analyseregeln und auch zum Konfigurieren von NuGet-Analysepaketen verwendet werden.
EditorConfig im Vergleich zu Regelsätzen
Sollte ich meine Analyzer mithilfe eines Regelsatzes oder einer EditorConfig-Datei konfigurieren?
Regelsätze und EditorConfig-Dateien können koexistieren und beide zum Konfigurieren von Analysegeräten verwendet werden. Sowohl EditorConfig-Dateien als auch Regelsätze ermöglichen es Ihnen, Regeln zu aktivieren und zu deaktivieren und deren Schweregrad festzulegen.
In Visual Studio 2019, Version 16.5 und höher, werden Regelsatzdateien jedoch zugunsten von EditorConfig-Dateien veraltet, und .NET Core- und .NET 5+-Projekte unterstützen nicht alle Menübefehle für den Regelsatz. Weitere Informationen finden Sie unter Konvertieren einer vorhandenen Regelsatzdatei in eine EditorConfig-Datei.
EditorConfig-Dateien bieten zusätzliche Möglichkeiten zum Konfigurieren von Regeln:
- Für die .NET-Codequalitätsanalyse können Sie mit EditorConfig-Dateien definieren, welche Codetypen analysiert werden sollen.
- Für die .NET-Codeformatanalyse und .NET-Codequalitätsanalyse können Sie mit EditorConfig-Dateien die bevorzugten Codeformatvorlagen für eine Codebasis definieren .
Zusätzlich zu Regelsätzen und EditorConfig-Dateien werden einige Analyzer über 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 verwendet werden, um Regeln zu aktivieren und den Schweregrad in Visual Studio 2019, Version 16.3 und höher, festzulegen.
- EditorConfig-Dateien können nicht zum Konfigurieren der Legacyanalyse verwendet werden, während Regelsätze möglich sind.
Codeanalyse in CI-Builds (Continuous Integration)
Funktioniert die .NET Compiler Platform-basierte Codeanalyse in Ci-Builds (Continuous Integration)?
Ja. Bei Analysegeräten, die mit .NET SDK 5.0 oder höher oder aus einem NuGet-Paket installiert sind, werden diese Regeln zur Buildzeit erzwungen, einschließlich während eines CI-Builds. In CI-Builds verwendete Analyzer respektieren die Regelkonfiguration von Regelsätzen und EditorConfig-Dateien. Ab .NET 5.0 sind die in Visual Studio integrierten Codestilanalyses ebenfalls im .NET SDK enthalten, und die meisten davon sind in einem CI-Build erzwingbar. Weitere Informationen finden Sie unter Enable on build.
IDE-Analysegeräte im Vergleich zu StyleCop
Was ist der Unterschied zwischen den Visual Studio IDE-Codeanalysatoren und StyleCop-Analyzern?
Die Visual Studio-IDE enthält integrierte Analysegeräte, die sowohl nach Codestil- als auch Qualitätsproblemen suchen. Diese Regeln helfen Ihnen, neue Sprachfeatures zu verwenden, während sie eingeführt und die Verwendbarkeit Ihres Codes verbessert werden. Die IDE-Analysegeräte werden ständig mit jeder Visual Studio-Version aktualisiert.
StyleCop-Analysatoren sind Drittanbieteranalysatoren , die als NuGet-Paket installiert sind, das die Stilkonsistenz in Ihrem Code überprüft. Im Allgemeinen können Sie mit StyleCop-Regeln persönliche Einstellungen für eine Codebasis festlegen, ohne eine Formatvorlage über eine andere zu empfehlen.
Codeanalysatoren im Vergleich zur Legacyanalyse
Was ist der Unterschied zwischen legacyanalyse und .NET Compiler Platform-based code analysis?
.NET Compiler Platform-basierte Codeanalyse analysiert Quellcode in Echtzeit und während der Kompilierung, während Legacyanalyse Binärdateien analysiert, nachdem der Build abgeschlossen wurde. Weitere Informationen finden Sie unter .NET Compiler Platform-basierte Analyse im Vergleich zur Legacyanalyse.
FxCop-Analysegeräte im Vergleich zu .NET-Analyzern
Was ist der Unterschied zwischen FxCop Analyzers und .NET Analyzern?
Sowohl FxCop-Analyzer als auch .NET-Analyzer beziehen sich auf die .NET Compiler Platform ("Roslyn") Analyseimplementierungen von FxCop CA-Regeln. Vor Visual Studio 2019 16.8 und .NET 5.0 wurden diese Analysegeräte als Microsoft.CodeAnalysis.FxCopAnalyzersNuGet-Paket ausgeliefert. Ab Visual Studio 2019 16.8 und .NET 5.0 sind diese Analyzer im .NET SDK enthalten. Sie sind auch als Microsoft.CodeAnalysis.NetAnalyzersNuGet-Paket verfügbar. Bitte ziehen Sie die Migration von FxCop-Analyzern zu .NET-Analyzern in Betracht.
Behandeln von Warnungen als Fehler
Mein Projekt verwendet die Buildoption, um Warnungen als Fehler zu behandeln. Nach der Migration von der Legacyanalyse zur Quellcodeanalyse werden nun alle Codeanalysewarnungen als Fehler angezeigt. Wie kann ich das verhindern?
Führen Sie die folgenden Schritte aus, um zu verhindern, dass Codeanalysewarnungen als Fehler behandelt werden:
Erstellen Sie eine PROPS-Datei mit dem folgenden Inhalt:
<Project> <PropertyGroup> <CodeAnalysisTreatWarningsAsErrors>false</CodeAnalysisTreatWarningsAsErrors> </PropertyGroup> </Project>Fügen Sie ihrer .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, die die Props-Dateien der Analyse importieren. Wenn ihre PROPS-Datei beispielsweise den Namen "codeanalysis.props" hat:
... <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 Codeanalyse-Eigenschaftenseite für die Lösung?
Die Codeanalyse-Eigenschaftenseite auf Lösungsebene wurde zugunsten der zuverlässigeren freigegebenen Eigenschaftengruppe entfernt. Für die Verwaltung der Codeanalyse auf Projektebene ist die Codeanalyse-Eigenschaftenseite weiterhin verfügbar. (Für verwaltete Projekte empfehlen wir auch die Migration von Regelsätzen zu EditorConfig für die Regelkonfiguration.) Zum Freigeben von Regelsätzen für mehrere/alle Projekte in einer Lösung oder einem Repository empfehlen wir, eine Eigenschaftengruppe mit der CodeAnalysisRuleSet-Eigenschaft in einer freigegebenen Props/Targets-Datei oder Datei "Directory.props/Directory.targets " zu definieren. Wenn Sie keine solchen allgemeinen Props oder Ziele haben, die alle Ihre Projekte importieren, sollten Sie erwägen, eine solche Eigenschaftengruppe zu einer Datei "Directory.props" oder einer Datei "Directory.targets " auf einem Lösungsverzeichnis der obersten Ebene hinzuzufügen, das automatisch in allen Projektdateien importiert wird, die im Verzeichnis oder in seinen Unterverzeichnissen definiert sind.