Share via

What’s new in Code Analysis for Visual Studio 2010

  • Article

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: https://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: https://msdn.microsoft.com/en-us/library/dd465181(VS.100).aspx.

New Rules

The following managed code analysis rules are new

CA1062

Validate arguments of public methods

CA1303

Do not pass literals as localized parameters

CA2000

Dispose objects before losing scope

CA2100

Review SQL queries for security vulnerabilities

CA2130

Security critical constants should be transparent

CA2131

Security critical types may not participate in type equivalence

CA2132

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

CA2133

Delegates must bind to methods with consistent transparency

CA2134

Methods must keep consistent transparency when overriding base methods

CA2135

Level 2 assemblies should not contain LinkDemands

CA2136

Members should not have conflicting transparency annotations

CA2137

Transparent methods must contain only verifiable IL

CA2138

Transparent methods must not call methods with the SuppressUnmanagedCodeSecurity attribute

CA2139

Transparent methods may not use the HandleProcessCorruptingExceptions attribute

CA2140

Transparent code must not reference security critical items

CA2140

Transparent code must not reference security critical items

CA2141

Transparent methods must not satisfy LinkDemands

CA2142

Transparent code should not be protected with LinkDemands

CA2143

Transparent methods should not use security demands

CA2144

Transparent code should not load assemblies from byte arrays

CA2145

Transparent methods should not be decorated with the SuppressUnmanagedCodeSecurityAttribute

CA2146

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

CA2147

Transparent methods may not use security asserts

CA2149

Transparent methods must not call native code

CA2202

Do not dispose objects multiple times

CA2204

Literals should be spelled correctly

CA2215

Dispose methods should call base class dispose

CA2241

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.

Metrics

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.

CA0061

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

CA0062

The rule 'RuleId' could not be found.

CA0063

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

CA0064

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

CA0065

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

CA0066

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

CA0067

Directory not found.

CA0068

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

CA0069

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

CA0070

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

CA1805

Do not initialize unnecessarily

  

CA2127

Security transparent assemblies should not contain security critical code

Replaced by CA2136

CA2128

Security transparent code should not assert

Replaced by CA2147

CA2129

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.

Conclusion

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

  • Anonymous
    March 22, 2010
    Was CA1805 dropped for technical reasons, or is there something else about it that warranted its removal?

  • Anonymous
    March 23, 2010
    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.

  • Anonymous
    March 31, 2010
    Will the next version of FxCop work with VisualStudio 2010 Professional?

  • Anonymous
    April 01, 2010
    Yes. It will behave the same as FxCop 1.36 did with Visual Studio 2008 Professional.

  • Anonymous
    April 20, 2010
    When the new version of FxCop available?

  • Anonymous
    April 29, 2010
    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.

  • Anonymous
    April 29, 2010
    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

  • Anonymous
    April 30, 2010
    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.

  • Anonymous
    April 30, 2010
    We do not have any plans to release the source code for this rule.

  • Anonymous
    April 30, 2010
    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.

  • Anonymous
    May 06, 2010
    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?

  • Anonymous
    May 10, 2010
    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.

  • Anonymous
    May 11, 2010
    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?

  • Anonymous
    May 11, 2010
    The next release of FxCop will be part of the next Windows SDK release. We can't disclose release dates at this point.

  • Anonymous
    June 14, 2010
    The comment has been removed