Jede Codeanalyseregel gehört zu einer Regelkategorie. Entwurfsregeln unterstützen z. B. der Einhaltung der .NET-Entwurfsrichtlinien und Sicherheitsregeln der Vermeidung von Sicherheitslücken. Es ist möglich, für eine ganze Kategorie von Regeln den Schweregrad zu konfigurieren. Auch die -Konfiguration zusätzlicher -Optionen pro Kategorie ist möglich.
Die folgende Tabelle gibt einen Überblick über die verschiedenen Regelkategorien für die Codeanalyse und enthält einen Link zu den Regeln der einzelnen Kategorien. Außerdem wird der Konfigurationswert aufgelistet, der in einer EditorConfig-Datei zum Massenkonfigurieren des Regelschweregrads pro Kategorie zu verwenden ist. Um beispielsweise den Schweregrad von Sicherheitsregelverletzungen als Fehler festzulegen, lautet der EditorConfig-Eintrag dotnet_analyzer_diagnostic.category-Security.severity = error.
Tipp
Das Festlegen des Schweregrads für eine Regelkategorie mithilfe der dotnet_analyzer_diagnostic.category-<category>.severity-Syntax gilt nicht für Regeln, die standardmäßig deaktiviert sind. Ab .NET 6 können Sie jedoch die AnalysisMode<Category>-Projekteigenschaft verwenden, um alle Regeln in einer Kategorie zu aktivieren.
Dokumentationsregeln unterstützen das Schreiben von gut dokumentierten Bibliotheken durch die ordnungsgemäße Verwendung von XML-Dokumentationskommentaren für extern sichtbare APIs.
Portabilitätsregeln unterstützen die Portabilität auf verschiedenen Plattformen. Interoperabilitätsregeln unterstützen die Interaktion mit COM-Clients.
Zuverlässigkeitsregeln unterstützen die Bibliotheks- und Anwendungszuverlässigkeit wie beispielsweise die ordnungsgemäße Arbeitsspeicher- und Threadverwendung.
* Verwenden Sie den EditorConfig-Wert dotnet_analyzer_diagnostic.category-CodeQuality.severity, um die folgenden Regeln zu aktivieren: IDE0051, IDE0052, IDE0064und IDE0076. Diese Regeln beginnen zwar mit „IDE“, sind aber technisch gesehen nicht Teil der Style-Kategorie.
Die Quelle für diesen Inhalt finden Sie auf GitHub, wo Sie auch Issues und Pull Requests erstellen und überprüfen können. Weitere Informationen finden Sie in unserem Leitfaden für Mitwirkende.
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
