New Managed Code Warnings in Visual Studio 2010
The following managed code analysis warnings have been added in Microsoft Visual Studio 2010:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
A security transparent method calls a method that is marked by using the SuppressUnmanagedCodeSecurityAttribute 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.
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.
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.
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.
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.
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.
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.
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.
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.
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 literal string in a method body contains one or more words that are not recognized by the Microsoft spelling checker library.
If a type inherits from a disposable type, it must call the Dispose method of the base type from its own Dispose method.
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.