Export (0) Print
Expand All

New Managed Code Warnings in Visual Studio 2012

Visual Studio contains the following new managed code analysis warnings:

CA1303

CA1303: Do not pass literals as localized parameters

An externally visible method passes a string literal as a parameter to a constructor or method in the .NET Framework class library, and that string should be localizable.

CA2000

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.

CA2100

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 that is built from user input is vulnerable to SQL injection attacks.

CA2130

CA2130: Security critical constants should be transparent

Transparency enforcement is not enforced for constant values because compilers inline constant values so that no lookup is required at run time. Constant fields should be security transparent so that code reviewers do not assume that transparent code cannot access the constant.

CA2131

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

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

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 is also raised on a method that binds a delegate that is transparent or safe-critical to a critical method.

CA2134

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 is also 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.

CA2135

CA2135: Level 2 assemblies should not contain LinkDemands

LinkDemands are deprecated in the level 2 security rule set. Instead of using LinkDemands to enforce security at JIT compilation time, mark the methods, types, and fields by using the SecurityCriticalAttribute attribute.

CA2136

CA2136: Members should not have conflicting transparency annotations

Transparency attributes are applied from code elements of larger scope to elements of smaller scope. The transparency attributes of code elements that have larger scope take precedence over transparency attributes of code elements that are contained in the first element. For example, a class that is marked by using the SecurityCriticalAttribute attribute cannot contain a method that is marked by using the SecuritySafeCriticalAttribute attribute.

CA2137

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

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.

CA2139

CA2139: Transparent methods may not use the HandleProcessCorruptingExceptions attribute

This rule is raised by any method that is transparent and attempts to handle a process corrupting exception by using the HandleProcessCorruptedStateExceptionsAttribute attribute. A process corrupting exception is a CLR version 4.0 exception classification of exceptions such as AccessViolationException. The HandleProcessCorruptedStateExceptionsAttribute attribute may be used only by security critical methods, and will be ignored if it is applied to a transparent method.

CA2140

CA2140: Transparent code must not reference security critical items

A code element that is marked by using the SecurityCriticalAttribute attribute is security critical. A transparent method cannot use a security critical element. If a transparent type attempts to use a security critical type, a TypeAccessException, MethodAccessException, or FieldAccessException is raised.

CA2141

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.

CA2142

CA2142: Transparent code should not be protected with LinkDemands

This rule is raised on transparent methods that require LinkDemands to access them. Security transparent code should not be responsible for verifying the security of an operation, and therefore should not demand permissions.

CA2143

CA2143: Transparent methods should not use security demands

Security transparent code should not be responsible for verifying the security of an operation, and therefore should not demand permissions. Security transparent code should use full demands to make security decisions and safe-critical code should not rely on transparent code to have made the full demand.

CA2144

CA2144: Transparent code should not load assemblies from byte arrays

The security review for transparent code is not as complete as the security review for critical code because transparent code cannot perform security sensitive actions. Assemblies that are loaded from a byte array might not be noticed in transparent code, and that byte array might contain critical, or more important safe-critical code, that does have to be audited.

CA2145

CA2145: Transparent methods should not be decorated with the SuppressUnmanagedCodeSecurityAttribute

Methods that are decorated by the SuppressUnmanagedCodeSecurityAttribute attribute have an implicit LinkDemand put upon any method that calls it. This LinkDemand requires that the calling code be security critical. Marking the method that uses SuppressUnmanagedCodeSecurity by using the SecurityCriticalAttribute attribute makes this requirement more obvious for callers of the method.

CA2146

CA2146: Types must be at least as critical as their base types and interfaces

This rule is raised when a derived type has a security transparency attribute that is not as critical as its base type or implemented interface. Only critical types can derive from critical base types or implement critical interfaces, and only critical or safe-critical types can derive from safe-critical base types or implement safe-critical interfaces.

CA2147

CA2147: Transparent methods may not use security asserts

Code that is marked as SecurityTransparentAttribute is not granted sufficient permissions to assert.

CA2149

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.

CA2202

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.

CA2204

CA2204: Literals should be spelled correctly

A literal string in a method body contains one or more words that are not recognized by the Microsoft spelling checker library.

CA2215

CA2215: Dispose methods should call base class dispose

If a type inherits from a disposable type, it must call the Dispose method of the base type from its own Dispose method.

CA2241

CA2241: Provide correct arguments to formatting methods

The format argument that is passed to System.String.Format does not contain a format item that corresponds to each object argument, or vice versa.

Show:
© 2014 Microsoft