Reliability rules

Reliability rules support library and application reliability, such as correct memory and thread usage. The reliability rules include:

Rule Description
CA2000: Dispose objects before losing scope Because an exceptional event might occur that will prevent the finalizer of an object from running, the object should be explicitly disposed before all references to it are out of scope.
CA2002: Do not lock on objects with weak identity An object is said to have a weak identity when it can be directly accessed across application domain boundaries. A thread that tries to acquire a lock on an object that has a weak identity can be blocked by a second thread in a different application domain that has a lock on the same object.
CA2007: Do not directly await a Task An asynchronous method awaits a Task directly.
CA2008: Do not create tasks without passing a TaskScheduler A task creation or continuation operation uses a method overload that does not specify a TaskScheduler parameter.
CA2009: Do not call ToImmutableCollection on an ImmutableCollection value ToImmutable method was unnecessarily called on an immutable collection from System.Collections.Immutable namespace.
CA2011: Do not assign property within its setter A property was accidentally assigned a value within its own set accessor.
CA2012: Use ValueTasks correctly ValueTasks returned from member invocations are intended to be directly awaited. Attempts to consume a ValueTask multiple times or to directly access one's result before it's known to be completed may result in an exception or corruption. Ignoring such a ValueTask is likely an indication of a functional bug and may degrade performance.
CA2013: Do not use ReferenceEquals with value types When comparing values using System.Object.ReferenceEquals, if objA and objB are value types, they are boxed before they are passed to the ReferenceEquals method. This means that even if both objA and objB represent the same instance of a value type, the ReferenceEquals method nevertheless returns false.
CA2014: Do not use stackalloc in loops. Stack space allocated by a stackalloc is only released at the end of the current method's invocation. Using it in a loop can result in unbounded stack growth and eventual stack overflow conditions.
CA2015: Do not define finalizers for types derived from MemoryManager<T> Adding a finalizer to a type derived from MemoryManager<T> may permit memory to be freed while it is still in use by a Span<T>.
CA2016: Forward the CancellationToken parameter to methods that take one Forward the CancellationToken parameter to methods that take one to ensure the operation cancellation notifications gets properly propagated, or pass in CancellationToken.None explicitly to indicate intentionally not propagating the token.
CA2018: The count argument to Buffer.BlockCopy should specify the number of bytes to copy When using Buffer.BlockCopy, the count argument specifies the number of bytes to copy. You should only use Array.Length for the count argument on arrays whose elements are exactly one byte in size. byte, sbyte, and bool arrays have elements that are one byte in size.