What’s new in Code Analysis for Visual Studio 2010

This post summarizes the new functionality you will experience sing the Code Analysis functionality in Visual Studio 2010. Note that Code Analysis is only available in the Premium and Ultimate editions of Visual Studio 2010.

Rule Sets

In Visual Studio 2010 you can manage the list of rules that are executed against your managed code using rule sets. Rule sets are persisted as xml files that may be included as part of your project or solution and checked into source code control along with your code. Visual Studio ships with several pre-defined rule sets

  • Basic Correctness
  • Basic Design Guidelines
  • Extended Correctness
  • Extended Design Guidelines
  • Globalization
  • Minimum Recommended
  • Security

The new rule set editor allows you to create your own custom rule sets. You access the rule set configuration dialog and rule set editor from the Project Properties \ Code Analysis tab. For more information on using rule sets see the MSDN documentation: http://msdn.microsoft.com/en-us/library/dd264949(VS.100).aspx.

You also have the ability to configure all projects in a solution to use the same rule set from the Solution Properties. See the MSDN documentation: http://msdn.microsoft.com/en-us/library/dd465181(VS.100).aspx.

New Rules

The following managed code analysis rules are new


Validate arguments of public methods


Do not pass literals as localized parameters


Dispose objects before losing scope


Review SQL queries for security vulnerabilities


Security critical constants should be transparent


Security critical types may not participate in type equivalence


Default constructors must be at least as critical as base type default constructors


Delegates must bind to methods with consistent transparency


Methods must keep consistent transparency when overriding base methods


Level 2 assemblies should not contain LinkDemands


Members should not have conflicting transparency annotations


Transparent methods must contain only verifiable IL


Transparent methods must not call methods with the SuppressUnmanagedCodeSecurity attribute


Transparent methods may not use the HandleProcessCorruptingExceptions attribute


Transparent code must not reference security critical items


Transparent code must not reference security critical items


Transparent methods must not satisfy LinkDemands


Transparent code should not be protected with LinkDemands


Transparent methods should not use security demands


Transparent code should not load assemblies from byte arrays


Transparent methods should not be decorated with the SuppressUnmanagedCodeSecurityAttribute


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


Transparent methods may not use security asserts


Transparent methods must not call native code


Do not dispose objects multiple times


Literals should be spelled correctly


Dispose methods should call base class dispose


Provide correct arguments to formatting methods

Rules CA1062, CA1303, CA2000, CA2100, CA2202, CA2204, CA2215 and CA2241 are all implemented using the new Phoenix analysis engine. We’ll discuss the Phoenix engine in a subsequent blog post.


We improved the accuracy of calculating several metrics for switch statements and catch blocks.

New errors and warnings that FxCopCmd will generate

The follow new error codes may be generated when FxCopCmd is unable to successfully analyze your code for one reason or another.


The rule 'RuleId' referenced in rule set 'RuleSetName' could not be found.


The rule 'RuleId' could not be found.


Failed to load rule set file or one of its dependent rule set files.


No analysis was performed because the specified rule set did not contain any FxCop rules.


Unsupported metadata construct: Type 'TypeName' contains both a property and a field with the same name 'PropertyFieldName'


The value '{0}' provided to the /targetframeworkversion is not a recognized version.


Directory not found.


Debug information could not be found for target assembly 'AssemblyName'.


UsingAlternatePlatform. FrameworkVersion1 could not be found. Using FrameworkVersion2 instead. For best analysis results please ensure that the correct .NET Framework is installed.


Unable to analyze permission attributes


Support for C# 4 language constructs


Support for C++ 0x language constructs


What’s gone

  • Policy Migration – TFS Checkin Policy

In Visual Studio 2008 you had the ability to copy your Code Analysis checkin policy settings from a TFS team project into the Solution / Project(s). This feature is not available in Visual Studio 2010. Use the new rule sets feature to configure the rules that will be executed during a build.

  • The following rules are no longer available


Do not initialize unnecessarily



Security transparent assemblies should not contain security critical code

Replaced by CA2136


Security transparent code should not assert

Replaced by CA2147


Security transparent code should not reference non-public security critical members

Replaced by CA2140

  • Managed C++ in-source suppression. Use the code analysis global suppression file. If you need the suppression attributes to be defined in your source code you will need to copy or move them from the global suppression file into your source code.


Questions and comments are welcome. You may either post a comment for this blog or post a question on the Code Analysis team’s MSDN forum.


The Visual Studio Code Analysis Team.

Comments (15)
  1. Derek says:

    Was CA1805 dropped for technical reasons, or is there something else about it that warranted its removal?

  2. Duke Kamstra says:

    We eliminated rule CA1805 because the cases where it fired weren’t really interesting or helpful. In a Release build the user’s code that is initializing a variable to the type’s default value gets optimized away by the compiler. In Debug builds most of the warnings are against generated code which the user can’t really do anything about.

  3. Mark Kamoski says:

    Will the next version of FxCop work with VisualStudio 2010 Professional?

  4. Duke Kamstra says:

    Yes. It will behave the same as FxCop 1.36 did with Visual Studio 2008 Professional.

  5. Syed Hussain says:

    When the new version of FxCop available?

  6. Daniel Smith says:

    Always great to have additional rules, however some of these new ones raise some questions:

    CA2000 (Dispose objects before losing scope) – We’re getting this on methods that return DataSets (which are IDisposable).  Is this correct?  This rule is also flagging up cases where we new up an IDisposable object and assign it to a local field, but we don’t want to dispose of it immediately – we do this in the owner class’s Dispose method.

    CA2100 (Review SQL queries for vulnerabilities) is also coming up with a number of false hits when we’re already using stored procedures.  We use a number of internal helper methods which take the stored procedure name as a parameter, but CA2100 thinks we’re passing in unchecked SQL strings.

  7. Duke Kamstra says:

    Please send us some code that demonstrates what you’re seeing. Given the infinite number of code possibilities it’s difficult for me to say if you are seeing false positives, limitations in the rules or actual issues with your code.

    Please post your qestions/code sample on our MSDN forum: http://social.msdn.microsoft.com/Forums/en-US/vstscode/threads

  8. sdorman says:

    Will the source code for CA1805 be made available for those that want to include it again? I always found that this fired more on code that other developers wrote and less on generated code (particularly since most generated code was/is excluded from analysis). I know that the runtime will optimize those calls away, but it is useful for new developers to see these issues and understand them.

  9. Duke Kamstra says:

    We do not have any plans to release the source code for this rule.

  10. sdorman says:

    If there are no plans to release the source code for CA1805, it would be nice to make it available as a separate rule DLL that can be included.

  11. Richard says:

    If I select the "Ignore compiler-generated code" option, it’s still generating warnings for code generated by the XAML designer – the partial classes for windows and user controls, and the XamlGeneratedNamespace.GeneratedInternalTypeHelper class.

    Is this a bug in the code analysis, or a bug in the XAML generated code? And is there an easy way to turn off warnings for these files without manually adding every warning to the global suppression file?

  12. Duke Kamstra says:

    This is a bug in the XAML code generator. In Visual Studio 2010 the XAML code generator adds the generated code attribute to the partial classes.

    Aside from turning off the rule entirely, there isn’t an easy way to turn off these warnings. Warning supression is on a per-warning basis.

  13. Dave says:

    Is there going to be a new FxCop release?  Or are all updates going to be within VS Code Analysis from now on?

    If there is going to be an release, when can we expect it?

  14. Duke Kamstra says:

    The next release of FxCop will be part of the next Windows SDK release. We can’t disclose release dates at this point.

  15. Thomas Tomiczek says:

    CA1062, thrown tons of times in XAML generated code in 2010 RTM. Nice crappy programming at one point from microsoft 😉

Comments are closed.

Skip to main content