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.
CA1009: Declare event handlers correctly	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.
CA1016: Mark assemblies with AssemblyVersionAttribute	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.
CA1033: Interface methods should be callable by child types	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.
CA1060: Move P/Invokes to NativeMethods class	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.
CA1061: Do not hide base class methods	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.
CA1063: Implement IDisposable correctly	All IDisposable types should implement the Dispose pattern correctly.
CA1065: Do not raise exceptions in unexpected locations	A method that is not expected to throw exceptions throws an exception.
CA1301: Avoid duplicate accelerators	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.
CA1400: P/Invoke entry points should exist	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.
CA1401: P/Invokes should not be visible	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.
CA1403: Auto layout types should not be COM visible	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.
CA1404: Call GetLastError immediately after P/Invoke	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.
CA1405: COM visible type base types should be COM visible	A COM-visible type derives from a type that is not COM-visible.
CA1410: COM registration methods should be matched	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.
CA1415: Declare P/Invokes correctly	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.
CA1900: Value type fields should be portable	This rule checks that structures declared with explicit layout will align correctly when marshaled to unmanaged code on 64-bit operating systems.
CA1901: P/Invoke declarations should be portable	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.
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.
CA2100: Review SQL queries for security vulnerabilities	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.
CA2101: Specify marshaling for P/Invoke string arguments	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.
CA2108: Review declarative security on value types	A public or protected value type is secured by Data Access or Link Demands.
CA2111: Pointers should not be visible	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.
CA2112: Secured types should not expose fields	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.
CA2114: Method security should be a superset of type	A method should not have both method-level and type-level declarative security for the same action.
CA2116: APTCA methods should only call APTCA methods	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.
CA2117: APTCA types should only extend APTCA base types	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.
CA2122: Do not indirectly expose methods with link demands	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.
CA2123: Override link demands should be identical to base	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.
CA2124: Wrap vulnerable finally clauses in outer try	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.
CA2126: Type link demands require inheritance demands	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.
CA2137: Transparent methods must contain only verifiable IL	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.
CA2141:Transparent methods must not satisfy LinkDemands	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.
CA2147: Transparent methods may not use security asserts	Code that is marked as SecurityTransparentAttribute is not granted sufficient permissions to assert.
CA2149: Transparent methods must not call into native code	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.
CA2200: Rethrow to preserve stack details	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.
CA2202: Do not dispose objects multiple times	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.
CA2207: Initialize value type static fields inline	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.
CA2212: Do not mark serviced components with WebMethod	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.
CA2213: Disposable fields should be disposed	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.
CA2214: Do not call overridable methods in constructors	When a constructor calls a virtual method, it is possible that the constructor for the instance that invokes the method has not executed.
CA2216: Disposable types should declare finalizer	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.
CA2220: Finalizers should call base class finalizer	Finalization must be propagated through the inheritance hierarchy. To guarantee this, types must call their base class Finalize method in their own Finalize method.
CA2229: Implement serialization constructors	To fix a violation of this rule, implement the serialization constructor. For a sealed class, make the constructor private; otherwise, make it protected.
CA2232: Mark Windows Forms entry points with STAThread	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.
CA2235: Mark all non-serializable fields	An instance field of a type that is not serializable is declared in a type that is serializable.
CA2236: Call base class methods on ISerializable types	To fix a violation of this rule, call the base type GetObjectData method or serialization constructor from the corresponding derived type method or constructor.
CA2237: Mark ISerializable types with SerializableAttribute	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.
CA2238: Implement serialization methods correctly	A method that handles a serialization event does not have the correct signature, return type, or visibility.
CA2240: Implement ISerializable correctly	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.
CA2241: Provide correct arguments to formatting methods	The format argument passed to System.String.Format does not contain a format item that corresponds to each object argument, or vice versa.
CA2242: Test for NaN correctly	This expression tests a value against Single.Nan or Double.Nan. Use Single.IsNan(Single) or Double.IsNan(Double) to test the value.