Microsoft Minimum Recommended Rules Code Analysis Rule Set
You can use the Microsoft Minimum Recommended Rules rule set to focus on the most critical problems in your code, including potential security holes, application crashes, and other important logic and design errors. You should include this rule set in any custom rule set that you create for your projects.
Rule |
Description |
|---|---|
CA1001: Types that own disposable fields should be disposable |
A class declares and implements an instance field that is a System.IDisposable type, and the class does not implement IDisposable. A class that declares an IDisposable field indirectly owns an unmanaged resource and should implement the IDisposable interface. |
Event handler methods take two parameters. The first is of type System.Object and is named "sender". This is the object that raised the event. The second parameter is of type System.EventArgs and is named "e". This is the data associated with the event. Event handler methods should not return a value; in the C# programming language, this is indicated by the return type void. |
|
The .NET Framework uses the version number to uniquely identify an assembly, and to bind to types in strong-named assemblies. The version number is used together with version and publisher policy. By default, applications run only with the assembly version with which they were built. |
|
An unsealed externally visible type provides an explicit method implementation of a public interface and does not provide an alternative externally visible method with the same name. |
|
CA1049: Types that own native resources should be disposable |
Types that allocate unmanaged resources should implement IDisposable, to enable callers to release those resources on demand and to shorten the lifetimes of the objects holding the resources. |
Platform Invocation methods, such as those marked with the System.Runtime.InteropServices.DllImportAttribute attribute, or methods defined by using the Declare keyword in Visual Basic, access unmanaged code. These methods should be of the NativeMethods, SafeNativeMethods, or UnsafeNativeMethods class. |
|
A method in a base type is hidden by an identically named method in a derived type, when the parameter signature of the derived method differs only by types that are more weakly derived than the corresponding types in the parameter signature of the base method. |
|
All IDisposable types should implement the Dispose pattern correctly. |
|
A method that is not expected to throw exceptions throws an exception. |
|
An access key, also known as an accelerator, enables keyboard access to a control by using the ALT key. When multiple controls have duplicate access keys, the behavior of the access key is not well-defined. |
|
A public or protected method is marked with the System.Runtime.InteropServices.DllImportAttribute attribute. Either the unmanaged library could not be located, or the method could not be matched to a function in the library. |
|
A public or protected method in a public type has the System.Runtime.InteropServices.DllImportAttribute attribute (also implemented by the Declare keyword in Visual Basic). Such methods should not be exposed. |
|
A COM-visible value type is marked with the System.Runtime.InteropServices.StructLayoutAttribute attribute set to LayoutKind.Auto. The layout of these types can change between versions of the .NET Framework, which will break COM clients that expect a specific layout. |
|
A call is made to the Marshal.GetLastWin32Error method or the equivalent Win32 GetLastError function, and the immediately previous call is not to a platform invoke method. |
|
A COM-visible type derives from a type that is not COM-visible. |
|
A type declares a method marked with the System.Runtime.InteropServices.ComRegisterFunctionAttribute attribute but does not declare a method marked with the System.Runtime.InteropServices.ComUnregisterFunctionAttribute attribute, or vice versa. |
|
This rule looks for platform invoke method declarations that target Win32 functions that have a pointer to an OVERLAPPED structure parameter and the corresponding managed parameter is not a pointer to a System.Threading.NativeOverlapped structure. |
|
This rule checks that structures declared with explicit layout will align correctly when marshaled to unmanaged code on 64-bit operating systems. |
|
This rule evaluates the size of each parameter and the return value of a P/Invoke, and verifies that their size is correct when marshaled to unmanaged code on 32-bit and 64-bit operating systems. |
|
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. |
|
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. |
|
A method sets the System.Data.IDbCommand.CommandText property by using a string that is built from a string argument to the method. This rule assumes that the string argument contains user input. A SQL command string built from user input is vulnerable to SQL injection attacks. |
|
A platform invoke member allows partially trusted callers, has a string parameter, and does not explicitly marshal the string. This can cause a potential security vulnerability. |
|
A public or protected value type is secured by Data Access or Link Demands. |
|
A pointer is not private, internal, or read-only. Malicious code can change the value of the pointer, potentially allowing access to arbitrary locations in memory or causing application or system failures. |
|
A public or protected type contains public fields and is secured by Link Demands. If code has access to an instance of a type that is secured by a link demand, the code does not have to satisfy the link demand to access the type's fields. |
|
A method should not have both method-level and type-level declarative security for the same action. |
|
When the APTCA (AllowPartiallyTrustedCallers) attribute is present on a fully trusted assembly, and the assembly executes code in another assembly that does not allow partially trusted callers, a security exploit is possible. |
|
When the APTCA (AllowPartiallyTrustedCallers) attribute is present on a fully trusted assembly, and a type in the assembly inherits from a type that does not allow partially trusted callers, a security exploit is possible. |
|
A public or protected member has Link Demands and is called by a member that does not perform any security checks. A link demand checks the permissions of the immediate caller only. |
|
This rule matches a method to its base method, which is either an interface or a virtual method in another type, and then compares the link demands on each. If this rule is violated, a malicious calle134r can bypass the link demand just by calling the unsecured method. |
|
A public or protected method contains a try/finally block. The finally block appears to reset the security state and is not itself enclosed in a finally block. |
|
A public unsealed type is protected with a link demand and has an overridable method. Neither the type nor the method is protected with an inheritance demand. |
|
CA2131: Security critical types may not participate in type equivalence |
A type participates in type equivalence and either the type itself, or a member or field of the type, is marked by using the SecurityCriticalAttribute attribute. This rule occurs on any critical types or types that contain critical methods or fields that are participating in type equivalence. When the CLR detects such a type, it does not load it with a TypeLoadException at run time. Typically, this rule is raised only when users implement type equivalence manually instead of in by relying on tlbimp and the compilers to do the type equivalence. |
CA2132: Default constructors must be at least as critical as base type default constructors |
Types and members that have the SecurityCriticalAttribute cannot be used by Silverlight application code. Security-critical types and members can be used only by trusted code in the .NET Framework for Silverlight class library. Because a public or protected construction in a derived class must have the same or greater transparency than its base class, a class in an application cannot be derived from a class marked as SecurityCritical. |
CA2133: Delegates must bind to methods with consistent transparency |
This warning is raised on a method that binds a delegate that is marked by using the SecurityCriticalAttribute to a method that is transparent or that is marked by using the SecuritySafeCriticalAttribute. The warning also is raised on a method that binds a delegate that is transparent or safe-critical to a critical method. |
CA2134: Methods must keep consistent transparency when overriding base methods |
This rule is raised when a method marked by using the SecurityCriticalAttribute overrides a method that is transparent or marked by using the SecuritySafeCriticalAttribute. The rule also is raised when a method that is transparent or marked by using the SecuritySafeCriticalAttribute overrides a method that is marked by using a SecurityCriticalAttribute. The rule is applied when overriding a virtual method or implementing an interface. |
A method contains unverifiable code or returns a type by reference. This rule is raised on attempts by security transparent code to execute unverifiable microsoft intermediate language (MISL). However, the rule does not contain a full IL verifier, and instead uses heuristics to catch most violations of MSIL verification. |
|
CA2138: Transparent methods must not call methods with the SuppressUnmanagedCodeSecurity attribute |
A security transparent method calls a method that is marked by using the SuppressUnmanagedCodeSecurityAttribute attribute. |
A security transparent method calls a method in an assembly that is not marked by using the APTCA, or a security transparent method satisfies a LinkDemand for a type or a method. |
|
CA2146: Types must be at least as critical as their base types and interfaces |
A security transparent method calls a method in an assembly that is not marked by using the APTCA, or a security transparent method satisfies a LinkDemand for a type or a method. |
Code that is marked as SecurityTransparentAttribute is not granted sufficient permissions to assert. |
|
This rule is raised on any transparent method that calls directly into native code (for example, through a P/Invoke). Violations of this rule lead to a MethodAccessException in the level 2 transparency model and a full demand for UnmanagedCode in the level 1 transparency model. |
|
An exception is re-thrown and the exception is explicitly specified in the throw statement. If an exception is re-thrown by specifying the exception in the throw statement, the list of method calls between the original method that threw the exception and the current method is lost. |
|
A method implementation contains code paths that could cause multiple calls to System.IDisposable.Dispose or a Dispose equivalent (such as a Close() method on some types) on the same object. |
|
A value type declares an explicit static constructor. To fix a violation of this rule, initialize all static data when it is declared and remove the static constructor. |
|
A method in a type that inherits from System.EnterpriseServices.ServicedComponent is marked with System.Web.Services.WebMethodAttribute. Because WebMethodAttribute and a ServicedComponent method have conflicting behavior and requirements for context and transaction flow, the behavior of the method will be incorrect in some scenarios. |
|
A type that implements System.IDisposable declares fields that are of types that also implement IDisposable. The Dispose method of the field is not called by the Dispose method of the declaring type. |
|
When a constructor calls a virtual method, it is possible that the constructor for the instance that invokes the method has not executed. |
|
A type that implements System.IDisposable, and has fields that suggest the use of unmanaged resources, does not implement a finalizer as described by Object.Finalize. |
|
Finalization must be propagated through the inheritance hierarchy. To guarantee this, types must call their base class Finalize method in their own Finalize method. |
|
To fix a violation of this rule, implement the serialization constructor. For a sealed class, make the constructor private; otherwise, make it protected. |
|
STAThreadAttribute indicates that the COM threading model for the application is a single-threaded apartment. This attribute must be present on the entry point of any application that uses Windows Forms; if it is omitted, the Windows components might not work correctly. |
|
An instance field of a type that is not serializable is declared in a type that is serializable. |
|
To fix a violation of this rule, call the base type GetObjectData method or serialization constructor from the corresponding derived type method or constructor. |
|
To be recognized by the common language runtime as serializable, types must be marked with the SerializableAttribute attribute even if the type uses a custom serialization routine through implementation of the ISerializable interface. |
|
A method that handles a serialization event does not have the correct signature, return type, or visibility. |
|
To fix a violation of this rule, make the GetObjectData method visible and overridable, and make sure that all instance fields are included in the serialization process or explicitly marked with the NonSerializedAttribute attribute. |
|
The format argument passed to System.String.Format does not contain a format item that corresponds to each object argument, or vice versa. |
|
This expression tests a value against Single.Nan or Double.Nan. Use Single.IsNan(Single) or Double.IsNan(Double) to test the value. |