Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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 Aufgaben 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 Auflistung 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: ValueTasks ordnungsgemäß verwenden | 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: ReferenceEquals nicht mit Werttypen verwenden | 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 count übergebene Buffer.BlockCopy-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: Enumerable.Cast<T> oder Enumerable.OfType<T> nicht mit inkompatiblen Typen aufrufen | Im Aufruf von Enumerable.Cast<TResult>(IEnumerable) oder Enumerable.OfType<TResult>(IEnumerable) wird ein Typparameter angegeben, der nicht mit dem Typ der Eingabeauflistung kompatibel ist. |
| CA2022: Vermeidung ungenauer Lesevorgänge mit Stream.Read | Ein Aufruf von Stream.Read kann weniger Bytes als angefordert zurückgeben, was zu unzuverlässigem Code führt, wenn der Rückgabewert nicht überprüft wird. |
| CA2023: Ungültige geschweifte Klammern in der Nachrichtenvorlage | Die Protokollierung von Nachrichtenvorlagen verwendet geschweifte Klammern { und }, um benannte Platzhalter für Werte zu kennzeichnen. Ungültige Klammernverwendung in Nachrichtenvorlagen kann zu Laufzeit-Ausnahmen oder unerwartetem Protokollierungsverhalten führen. |
| CA2024: StreamReader.EndOfStream nicht in asynchronen Methoden verwenden | Die Eigenschaft StreamReader.EndOfStream kann zu unbeabsichtigter synchroner Blockierung führen, wenn keine Daten gepuffert wurden. Verwenden Sie stattdessen direkt StreamReader.ReadLineAsync(), damit null zurückgegeben wird, sobald das Ende des Datenstroms erreicht wurde. |
CA2025: IDisposable-Instanzen nicht an nicht erwartete Tasks übergeben |
Unerwartete Aufgaben, die IDisposable-Instanzen verwenden, könnten diese Instanzen noch lange nach deren Entsorgung verwenden. Stellen Sie sicher, dass Aufgaben, die diese Instanzen verwenden, abgeschlossen werden, bevor die Instanzen entfernt werden. |
| CA2026: Bevorzugen Sie JsonElement.Parse gegenüber JsonDocument.Parse().RootElement | Es ist effizienter, direkt anzurufen JsonElement.Parse als anrufen JsonDocument.Parse().RootElement. |
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.