Zuverlässigkeitsregeln
Zuverlässigkeitsregeln unterstützen die Bibliotheks- und Anwendungszuverlässigkeit wie beispielsweise die ordnungsgemäße Arbeitsspeicher- und Threadverwendung. Die Zuverlässigkeitsregeln umfassen Folgendes:
Regel | Beschreibung |
---|---|
CA2000: Objekte verwerfen, bevor Bereich verloren geht. | Da eine Ausnahme auftreten kann, durch die die Ausführung eines Objektfinalizers verhindert wird, sollte das Objekt explizit verworfen werden, bevor sich sämtliche Verweise auf dieses außerhalb des Bereichs befinden. |
CA2002: Auf Objekten mit schwacher Identität nicht sperren. | Ein Objekt hat eine schwache Identität, wenn ein Zugriff darauf über Grenzen von Anwendungsdomänen hinweg möglich ist. Ein Thread, der eine Sperre für ein Objekt zu erhalten versucht, das über eine schwache Identität verfügt, kann durch einen zweiten Thread in einer anderen Anwendungsdomäne blockiert werden, der eine Sperre für das gleiche Objekt besitzt. |
CA2007: Eine Aufgabe nicht direkt abwarten | Eine asynchrone Methode wartet direkt auf eine Aufgabe (Task). |
CA2008: Keine Tasks ohne Übergabe eines TaskSchedulers erstellen | Eine Taskerstellung oder ein Fortsetzungsvorgang verwendet eine Methodenüberladung, die keinen TaskScheduler-Parameter angibt. |
CA2009: „ToImmutableCollection“ nicht für einen ImmutableCollection-Wert aufrufen. | Die ToImmutable -Methode wurde unnötigerweise für eine unveränderliche Sammlung aus dem System.Collections.Immutable-Namespace aufgerufen. |
CA2011: Eigenschaft nicht innerhalb ihres Setters zuweisen | Einer Eigenschaft wurde versehentlich ein Wert innerhalb ihrer eigenen set-Zugriffsmethode zugewiesen. |
CA2012: Verwenden Sie ValueTasks ordnungsgemäß. | ValueTasks, die von Memberaufrufen zurückgegeben werden, sollten direkt erwartet werden. Alle Versuche, einen ValueTask mehrmals zu verwenden oder direkt auf ein Ergebnis zuzugreifen, bevor es als abgeschlossen bezeichnet wird, können zu einer Ausnahme oder Beschädigung führen. Das Ignorieren eines solchen ValueTask ist wahrscheinlich ein Hinweis auf einen Funktionsfehler und kann die Leistung beeinträchtigen. |
CA2013: Verwenden Sie ReferenceEquals nicht mit Werttypen. | Wenn objA und objB beim Vergleichen von Werten mithilfe von System.Object.ReferenceEquals Werttypen sind, werden sie geschachtelt, bevor sie an die ReferenceEquals-Methode übergeben werden. Dies bedeutet, dass die ReferenceEquals-Methode selbst dann „false“ zurückgibt, wenn objA und objB dieselbe Instanz eines Werttyps darstellen. |
CA2014: stackalloc nicht in Schleifen verwenden | Der von einem stackalloc-Ausdruck zugewiesene Stapelspeicher wird nur am Ende des Aufrufs der aktuellen Methode freigegeben. Die Verwendung in einer Schleife kann zu einem unbegrenzten Stapelwachstum und letztlichen Stapelüberlauf führen. |
CA2015: Keine Finalizer für von MemoryManager<T> abgeleitete Typen definieren | Durch das Hinzufügen eines Finalizers zu einem von MemoryManager<T> abgeleiteten Typ wird möglicherweise Arbeitsspeicher freigegeben, der noch von einem Span<T>-Element verwendet wird. |
CA2016: Parameter "CancellationToken" an Methoden weiterleiten, die diesen Parameter akzeptieren. | Leiten Sie den CancellationToken -Parameter an Methoden weiter, die diesen akzeptieren, um sicherzustellen, dass die Benachrichtigungen zum Abbruch des Vorgangs ordnungsgemäß weitergegeben werden. Alternativ dazu können Sie explizit CancellationToken.None übergeben, um festzulegen, dass das Token nicht verteilt werden soll. |
CA2017: Konflikt bei der Parameteranzahl | Die Anzahl der in der Vorlage für Protokollierungsnachrichten angegebenen Parameter stimmt nicht mit der Anzahl benannter Platzhalter überein. |
CA2018: Das an Buffer.BlockCopy übergebene count -Argument sollte die Anzahl der zu kopierenden Bytes angeben |
Wenn Sie Buffer.BlockCopy verwenden, gibt das count -Argument die Anzahl der zu kopierenden Bytes an. Sie sollten Array.Length nur für das count -Argument in Arrays verwenden, deren Elemente genau ein Byte groß sind. byte -, sbyte - und bool -Arrays weisen Elemente auf, die ein Byte groß sind. |
CA2019: ThreadStatic -Felder dürfen keine Inlineinitialisierung verwenden. |
Ein Feld, das mit einer ThreadStaticAttribute-Anmerkung versehen ist, wird inline oder explizit in einem static -Konstruktor (Shared in Visual Basic) initialisiert. |
CA2020: Verhindern von Verhaltensänderungen durch integrierte Operatoren von IntPtr/UIntPtr | Einige integrierte Operatoren, die in .NET 7 hinzugefügt wurden, verhalten sich anders als die benutzerdefinierten Operatoren in .NET 6 und früheren Versionen. Einige Operatoren, die normalerweise während des Überlaufs in ungeprüftem Kontext ausgelöst haben, lösen nicht mehr aus, es sei denn, sie werden in überprüften Kontext eingeschlossen. Einige Operatoren, die zuvor in überprüftem Kontext nicht ausgelöst haben, lösen jetzt aus, es sei denn, sie sind in nicht überprüften Kontext eingeschlossen. |
CA2021: Rufen Sie Enumerable.Cast<T> oder Enumerable.OfType<T> nicht mit inkompatiblen Typen auf | Ein Aufruf Enumerable.Cast<TResult>(IEnumerable) oder Enumerable.OfType<TResult>(IEnumerable) gibt einen Typparameter an, der nicht mit dem Typ der Eingabeauflistung kompatibel ist. |
Zusammenarbeit auf GitHub
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.