This blog explains how to implement your own static code analysis rules for analyzing your .NET (C#, VB.NET, etc) code. The material was written by Todd King, one of the developers on the Visual Studio Code Analysis team.

NOTE: Writing custom FxCop rules, the associated APIs and the process for installing them is not a supported feature of the product. We are providing this information because we get so many questions about how to do it.

Prerequisites

You must be using Visual Studio 2010 Premium or Visual Studio 2010 Ultimate to implement custom code analysis rules.

Creating the MyCustomRules project

NOTE: If you already have an existing custom rules project you can skip this step.

1. Create a new class library project and name it whatever you want your rules assembly to be named. For the purposes of this blog I’ve named it MyCustomRules.

2. Next add a reference to the FxCop assemblies. Your custom rules project will need to reference FxCopSdk.dll and Microsoft.Cci.dll. Visual Studio 2010 installs the assemblies in “C:\Program Files\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\FxCop” on a 32-bit OS and “C:\Program Files (x86)\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\FxCop” on a 64-bit OS. In order to avoid path resolution issues when the project is built on different computers you can use the $(CodeAnalysisPath) MSBuild property. The property will resolve to the location where the FxCop assemblies have been installed. Use the following procedure to define the references to the two assemblies

   1. Open up your project in Visual Studio 2010.

   2. In Solution Explorer right click on the project and select Unload Project

   3. Now right click on the project and select edit MyCustomRules.csproj

   4. Find the ItemGroup xml element where your project’s references are and add the first two <Reference> elements described in the following code snippet

      1. <ItemGroup>
      2.   <ReferenceInclude="FxCopSdk">
      3.     <HintPath>$(CodeAnalysisPath)\FxCopSdk.dll</HintPath>
      4.     <Private>False</Private>
      5.   </Reference>
      6.   <ReferenceInclude="Microsoft.Cci">
      7.     <HintPath>$(CodeAnalysisPath)\Microsoft.Cci.dll</HintPath>
      8.     <Private>False</Private>
      9.   </Reference>
      10.   <ReferenceInclude="System" />
      11.   <ReferenceInclude="System.Core" />
      12.   <ReferenceInclude="System.Xml.Linq" />
      13.   <ReferenceInclude="System.Data.DataSetExtensions" />
      14.   <ReferenceInclude="Microsoft.CSharp" />
      15.   <ReferenceInclude="System.Data" />
      16.   <ReferenceInclude="System.Xml" />
      17. </ItemGroup>

   5. Close the editor, right click on the project and select Reload Project.

3. Now we need to setup the RuleMetadata.xml file for this project. The RuleMetadata.xml file is where various properties of the rules for this project will be stored. For example this is where the rule description, resolutions, message level, owner contact info, etc is stored.

   1. To Add a RuleMetadata.xml file right click on your project and select add new item.

      1. Type XML File in the Search Installed Templates control.

      2. Select the XML File template and name it RuleMetadata.xml (it can be named whatever you want, for the purposes of this blog I’ve named it RuleMetadata.xml).

   2. At this point you don’t have any rules so all you need to do is add a root Rules element as follows. Where the FriendlyName value is some user readable string that will be displayed to the user as the name of your rules assembly.

      1. <?xmlversion="1.0"encoding="utf-8" ?>
      2. <RulesFriendlyName="My Custom FxCop Rules">

4. Next set the RuleMetadata.xml file as an EmbeddedResource for our rules assembly

   1. In Solution Explorer right click on the file RuleMetadata.xml and select Properties

   2. In the Property Tool window change the Build Action property to Embedded Resource.

Implementing a custom rule

Note that we have not released an SDK for implementing custom rules, so the API is undocumented and will almost certainly change in the future. With those caveats in mind, the following example describes how to implement a simple rule. The rule we will implement checks whether or not the identifiers for private and internal fields use Hungarian notation.

1. Define an abstract class that inherits from the FxCop API and initializes the resources defined in the XML file.

1. using Microsoft.FxCop.Sdk;
2.  
3. namespace MyCustomFxCopRules
4. {
5.     
6.     internalabstractclassBaseFxCopRule : BaseIntrospectionRule
7.     {
8.         protected BaseFxCopRule(string ruleName)
9.             : base(ruleName, "DukesFirstFxCopRule.DukesFirstFxCopRule", typeof(BaseFxCopRule).Assembly)
10.         { }
11.     }
12.  
13. }

Where the resource name is the default namespace of your project + whatever you named the RuleMetadata.xml file. "MyCustomFxCopRules.RuleMetadata" in the example above.

NOTE: Make sure you use the default namespace for your project in the resource name. If you do not FxCopCmd.exe will return error CA0054 because it is unable to load your rule.

2. Define a class to implement the rule and derive from our previously defined class.

1. internalsealedclassEnforceHungarianNotation : BaseFxCopRule
2. {
3.     public EnforceHungarianNotation()
4.         : base("EnforceHungarianNotation")
5.     { }
6. }

3. Define the visibility of the code elements we want to analyze by overriding the TargetVisibility property. Normally it is fine to leave this at the default implementation of TargetVisibilities.All however in this case we only want to analyze fields that are not externally visible so we want to return a value of TargetVisibilities.NotExternallyVisible. Add the following code to the EnforceHungarianNotation class definition.

1. // Only fire on non-externally visible code elements.
2. publicoverrideTargetVisibilities TargetVisibility
3. {
4.     get
5.     {
6.         returnTargetVisibilities.NotExternallyVisible;
7.     }
8. }

4. Since this rule is supposed to fire on fields, which are members of types, we override the Check(Member) method. We need to verify that the member being examined by the check method is actually a field. This could be done either by trying to cast it to a Microsoft.FxCop.Sdk.Field type or checking if the member’s NodeType is NodeType.Field. Once we know we are looking at a field we need to determine if it is a static field or not so we know which kind of Hungarian prefix should be expected. To do this we can check the IsStatic property on the field. Now we just need to determine if the field’s name starts with the expected Hungarian notation prefix and if not report a rule violation. To do this we get the field’s name using the Name property (actually need to call Name.Name to get the string form of the name, just one of the quirks of the current API) and check if it starts with the expected prefix. If not then we need to construct a Problem object and add it to the rule’s ProblemCollection accessed through the inherited Problems property. Add the following code to the EnforceHungarianNotation class definition.

1. publicoverrideProblemCollection Check(Member member)
2. {
3.     Field field = member asField;
4.     if (field == null)
5.     {
6.         // This rule only applies to fields.
7.         // Return a null ProblemCollection so no violations are reported for this member.
8.         returnnull;
9.     }
10.  
11.     if (field.IsStatic)
12.     {
13.         CheckFieldName(field, s_staticFieldPrefix);
14.     }
15.     else
16.     {
17.         CheckFieldName(field, s_nonStaticFieldPrefix);
18.     }
19.  
20.     // By default the Problems collection is empty so no violations will be reported
21.     // unless CheckFieldName found and added a problem.
22.     return Problems;
23. }
24. privateconststring s_staticFieldPrefix = "s_";
25. privateconststring s_nonStaticFieldPrefix = "m_";

5. Rule resolutions are stored in the RuleMetadata.xml file. Calling GetResolution will retrieve that resolution string and also fill in any string arguments passed in. Finally we need to create a Problem object from the Resolution object we just created and add that Problem to the Problems collection for this rule. Add the following code to the EnforceHungarianNotation class definition.

1. privatevoid CheckFieldName(Field field, string expectedPrefix)
2. {
3.     if (!field.Name.Name.StartsWith(expectedPrefix, StringComparison.Ordinal))
4.     {
5.         Resolution resolution = GetResolution(
6.           field,  // Field {0} is not in Hungarian notation.
7.           expectedPrefix  // Field name should be prefixed with {1}.
8.           );
9.         Problem problem = newProblem(resolution);
10.         Problems.Add(problem);
11.     }
12. }

6. The final step is adding the appropriate rule metadata for this new rule to the RuleMetadata.xml file in our project. The following rule metadata can be defined in the RuleMetadata file.

• Display name of the rule.
• Rule description.
• One or more rule resolutions.
• The MessageLevel (severity) of the rule. This can be set to one of the following:
  • CriticalError
  • Error
  • CriticalWarning
  • Warning
  • Information
• The certainty of the violation. This field represents the accuracy percentage of the rule. In other words this field describes the rule author’s confidence in how accurate this rule is.
• The FixCategory of this rule. This field describes if fixing this rule would require a breaking change, ie a change that could break other assemblies referencing the one being analyzed.
• The help url for this rule.
• The name of the owner of this rule.
• The support email to contact about this rule.

For the example EnforceHungarianNotation rule described in this sample the RuleMetadata.xml file should look something like:

1. <?xmlversion="1.0"encoding="utf-8" ?>
2. <RulesFriendlyName="My Custom FxCop Rules">
3.   <RuleTypeName="EnforceHungarianNotation"Category="MyRules"CheckId="CR1000">
4.     <Name>Enforce Hungarian Notation</Name>
5.     <Description>Checks fields for compliance with Hungarian notation.</Description>
6.     <Resolution>Field {0} is not in Hungarian notation. Field name should be prefixed with '{1}'.</Resolution>
7.     <MessageLevelCertainty="100">Warning</MessageLevel>
8.     <FixCategories>NonBreaking</FixCategories>
9.     <Url />
10.     <Owner />
11.     <Email />
12.   </Rule>
13. </Rules>

NOTE: The TypeName attribute of the Rule element must match exactly with the name string passed in to the base constructor of the rule implementation. If they do not match FxCopCmd.exe will return error CA0054 because it is unable to load your rule.

Debugging custom rules

You can debug custom rules through FxCopCmd.exe. Normally you would run your rule against another project. To simplify the instructions in this blog we’re going to run our new rule against the implementation of the rule itself. In the project properties for your custom rules project on the Debug tab do the following

1. Configure the project to launch an external program and enter in the path to FxCopCmd.exe. For example
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\FxCop\FxCopCmd.exe

2. For command line arguments specify
/out:"results.xml" /file:"MyCustomRules.dll" /rule:"MyCustomRules.dll" /D:"C:\Program Files (x86)\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\FxCop"

3. Set the working directory to the build output folder. For example
C:\Projects\MyCustomRules\MyCustomRules\bin\Debug\

Now you can to debug your custom rules by simply hitting F5 from your custom rules project. Try it

1. Set a breakpoint on the statement

1. if (!field.Name.Name.StartsWith(expectedPrefix, StringComparison.Ordinal))

2. Press F5 and execution should stop at the breakpoint.

3. Press F5 again and execution should complete successfully.

4. Note that there is not a results.xml file in the …\Debug folder because there are no rule violations in the code we are running the rule against.

Let’s create a rule violation so we can verify that our rule is behaving as it should.

1. Add the following code to the EnforceHungarianNotation class definition

1. privatestaticint m_Foo;

2. Press F5

3. Disable the breakpoint and Press F5 again

4. Examine the results.xml file in the …\Debug folder. Note the description of the rule violation. It works!

Running custom rules

At this point we have verified that our rule functions as expected. To run our custom rule using the command line utility FxCopCmd simply use the command line options we defined in the Debug options. Run FxCopCmd.exe /? For a list of all the command line utility’s options.

A new feature in Visual Studio 2010 is called rule sets. Rule sets are a new way of configuring which rules should be run during analysis. The easiest way to integrate your rules into Visual Studio 2010 is to copy them to the %Program Files%\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\FxCop\Rules directory. If you are replacing an existing assembly you will need to restart Visual Studio after copying the file. Once the file is copied to the Rules directory the next time you launch the rule set editor you should see your custom rules. Try the following procedure

1. From your project’s property settings select the Code Analysis tab

2. Click on the Open button to open the Rule Set editor

3. Create a custom rule set by doing a File à Save As and saving the rule set to MyCustomRuleSet.ruleset

4. Click on the button Show rules that are not enabled in the rule set editor’s button bar. Your custom rule(s) should appear in the list.

If you don’t want to mess with your Visual Studio installation by adding your own custom rules to the built in Rules directory that Visual Studio uses, you can manually edit a custom rule set instead.

1. Create a new rule set and save it.

2. Open that new rule set file in a text or xml editor and add a RuleHintPaths section with a Path element with the location of your custom rules. The path to your custom rules can include absolute file paths, relative paths, and use environment variables. For example your rule set file might look like the following:

1. <?xmlversion="1.0"encoding="utf-8"?>
2. <RuleSetName="My Custom Rule Set"Description=""ToolsVersion="10.0">
3.   <RuleHintPaths>
4.     <Path>%CustomRulesPath%</Path>
5.     <Path>..\..\CustomRules</Path>
6.     <Path>C:\CustomRules</Path>
7.   </RuleHintPaths>
8. </RuleSet>

3. Now open that rule set file with the visual studio Code Analysis Rule Set Editor (the default editor for *.ruleset files). Your custom rules should appear in the editor as seen above.

Troubleshooting Visual Studio integration

If code analysis is reporting errors performing analysis due to exceptions, more details on those exceptions can be found in the *.CodeAnalysisLog.xml file in the bin directory of the assembly being analyzed (see the Exceptions section of the report file towards the bottom).

When you run code analysis from Visual Studio the FxCopCmd command line utility is invoked to perform the analysis. To discover exactly what command line options are being passed to FxCopCmd by Visual Studio so you can reproduce and debug the error outside of Visual Studio, first set the build output verbosity to Normal or higher. This can be done by going to Tools - >Options -> Projects and Solutions -> Build and Run.

Run code analysis and view the output window. You should see the exact command line arguments passed into FxCopCmd right after the “Running Code Analysis…” message.

For more information on where FxCopCmd is looking for assemblies you may increase the trace level of FxCopCmd to 3. This can be done by modifying the FxCopCmd.exe.config file in the same directory as FxCopCmd.exe as follows

1.  
2. <switches>
3.   <!--
4.         TraceSwitch has the following values
5.           Off = 0, Error = 1, Warning = 2, Info = 3, Verbose = 4
6.                   
7.         BooleanSwitch has the following values
8.           Off = 0, On = 1        
9.       -->
10.  
11.   <!-- TraceSwitch'es -->
12.   <addname="Trace"value="3" />
13.  
14.   <!-- BooleanSwitch'es -->
15.   <addname="TraceExceptions"value="0" />
16. </switches>

Once this is done the xml reports (like the *.CodeAnalysisLog.xml file mentioned earlier) produced by FxCopCmd will contain a DebugInfo section that details what search paths FxCopCmd used and exactly where it resolved each assembly reference to. This information can also be determined by examining the trace messages emitted by FxCopCmd to the console.

This blog post applies to Visual Studio 2010 Premium and Ultimate editions. The content was written by Kevin Blasko one of the developers on the Visual Studio Code Analysis team.

The purpose of this blog post is to give you some background on the implementation of the Dataflow Analysis (DFA) rules in Visual Studio 2010.

New Engine, New Rules for Visual Studio 2010

If you looked at the What’s New in Visual Studio 2010 Blog Post you will have noticed that there are several new Code Analysis rules for Managed Code. Several of these new rules are what we describe as DFA rules. These rules are implemented using the Phoenix Code Analysis engine. The rules are:

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

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

This list of rules should give you an idea of what a DFA engine is capable of.

Why Implement A New Code Analysis Engine?

We needed to implement a new analysis engine to improve the quality and performance of DFA rules. We chose to do this using a technology developed by Microsoft Research called Phoenix. Phoenix is an extensible compiler framework with advanced analysis capabilities. Static analysis turns out to be very important to compilers since the more information you have about the state of the program, the better optimizations you can make when compiling the program. We took advantage of the existing analysis infrastructure as a starting point and built our new engine on top of it. The engine is capable of producing better quality analysis with less noise, less missed analysis, and better performance than our previous DFA engine.

The Phoenix engine excels at analyzing function bodies. Whereas the engine used for the rest of the managed code rules is good at symbolic analysis of class and function definitions (which the Phoenix engine can do as well). For example, consider the following simple example that is actually difficult to analyze without an engine with Phoenix’s capabilities. For the sample, assume that we’re trying to detect violations of CA1062 Validate Arguments of Public Methods.

Looking at “Function”, you can see that line 11 contains a CA1062 violation while line 7 does not, but how can you determine this programmatically? The code will first need to determine which object dereferences could potentially result in a violation. As the assignment on line 3 shows, this isn’t as straight forward as it first appears. In addition to looking for “argument” dereferences, you now need to look for dereferences of “localVariable”.

Now that you’ve found all of the potential dereferences, you need to determine whether or not it’s possible for “argument’s” value to be null for that particular dereference. If you’ve written code that is able to detect that “localVariable” dereferences need to be checked, it probably isn’t that hard to look for null checks against both “argument” and “localVariable”, so the next problem is finding the correct “if” statement that determines whether the dereference is executed. Like before, this is harder than it looks. It’s easy to tell that the dereferences occur within the scope of the “if-else” statement on line 5 and 9 by looking at the code. However, if you’re using an analysis engine whose object model is little more than a wrapper over the raw MSIL, the instructions that you’re analyzing have no concept of scope. The easiest thing that you can do is walk the instructions backwards looking for a branch instruction. But what happens if there’s a branch from further down in the program to line 7 or 11? That branch that you found could turn out to actually be a loop! Or even worse, the author could have inserted a goto that jumps directly to line 7!

Assuming that you get all of the control flow problems sorted out and are able to match the dereference to the branch instruction (maybe you build your own control flow graph or decide that walking the instructions back to the first branch is good enough), you now need to determine if the branch is conditional, and if so, if the condition is a null check. In cases like the one in the example, this will be easy enough, but in many cases, the condition will be the result of a more complex comparison or maybe not even a direct comparison at all. Depending on what you’re willing to accept here, things can get real complicated very fast.

So how does a DFA engine make this easier? The key benefit of a DFA engine is its ability to propagate known information about program state through a method using a control flow graph. New information about the state of the program is then discovered using the information that is known initially. The new information is then fed back into the system and used to further understand the state of the program. The information is propagated by applying a set of rules to the input data depending on the type of MSIL instruction that is being analyzed. This allows you to think about each propagation rule in isolation and only have to worry about what the output is for a narrow and more specific set of inputs.

In the example above, you would have a propagation rule for a compare instruction that takes “localVariable” and “null” as its inputs. Since we know that the literal value for “null” is null, we are able to infer new information about the null-ness of “localVariable” depending on which branch of the “if” statement is taken. As the output of this propagation rule, we would annotate each branch in the control flow graph with the null-ness information that we just inferred. This makes writing the Code Analysis rule simple. All we do is run the null-ness dataflow analysis, look for the dereferences of “argument” (which itself can be done as another dataflow analysis) and then extract the null-ness information for the object being dereferenced.

What Does This Cost Me?

This improved analysis does come at a cost to the Code Analysis user. It turns out that enabling even just one of the DFA rules will approximately double the time it takes to run code analysis. The reason for this is that both the Phoenix engine and the existing (Introspection aka CCI) engine need to load the target assembly and all the references into their own internal representations and then prepare those representations for rule consumption. The good news is that the amount of time it takes to execute all of the DFA rules isn’t that much different than executing one rule. To offset the performance hit, we’ve improved the performance of the Introspection engine so that it runs about 25% faster than the Visual Studio 2008 version.

NOTE: The Phoenix Code Analysis engine and associated DFA rules do not ship in the standalone FxCop release.

Version 10.0 of FxCop is the version that ships with Visual Studio 2010 Premium. FxCop 10.0 is part of Version 7.1 of the Microsoft Windows SDK for Windows 7 and .NET Framework 4.

Instructions

• Download the Microsoft Windows SDK for Windows 7 and .NET Framework 4 Version 7.1
• Using elevated privileges execute FxCopSetup.exe from the %ProgramFiles%\Microsoft SDKs\Windows\v7.1\Bin\FXCop folder.

Recently we have received several questions regarding Visual Studio Code Analysis integration with Team Foundation Server’s check-in policy and build server, so I thought it would be helpful to clarify the behavior and expose some relatively hidden functionality.

Source Control Check-in Policy

The first point of confusion that often arises is about the source control check-in policy.  A common question is “I have a check-in policy, so why does it let me check-in code that contains code analysis warnings?”, “I want a code analysis check-in policy, but I want to hold different projects (e.g. test and product code) to different standards, can I configure different check-in policies for different projects?”, or “How can I treat warnings as errors so I break the build on code analysis warnings?”

The important thing to note about the code analysis check-in policy is the rule set selected for the check-in policy sets the baseline for the minimum set of rules that must be run on the project before the code can be checked in.  All this does is enforce that the rules were run on the project before a check-in, it does not in fact enforce that the code checked-in be code analysis clean for the rule set that is specified in the check-in policy, nor does it actually require that exact rule set be run, as a superset of those rules can be run as long as each rule in the check-in policy rule set was run, the check-in will not be rejected.

The way to prevent checking in code with code analysis warnings is to modify the action for the rules from the default of “Warning” to “Error” for the rule set on the TFS server, setting the build definition trigger to be a “Gated Check-in”, and enabling Code Analysis as part of the build.  NOTE: taking this approach will also result in your builds breaking on code analysis warnings since you are treating them as errors.

Rule Sets

The first thing to do is pick the rule set(s) you want run for each project.  You can either use the built in rule sets, or create your own custom.   You will need to create at least one custom rule set if you want to use the same set of rules, but block check-ins for some projects, and with the same set of rules not block check-ins for other projects.  The easiest way to create a custom rule set is to start from an existing rule set:

• Open any project’s properties page
• Select the Code Analysis tab
• Choose the rule set you would like to make a copy of from the rule set drop down
• Click “Open”. 
  
• You will now be presented with the rule set editor, from the rule set editor change the action from “Warning” to “Error”
  
• When you save the modified rule set you will be presented with the “Save As…” dialogue since the built in rule sets are by default read only

You will now need to either place your new custom rule set on a share and set the project to use that rule set by selecting “<Browse…>” from the rule set dropdown, or you can drop the new custom rule set into the rule set directory (“%VS_INSTALL_DIRECTORY%\Team Tools\Static Analysis Tools\Rule Sets”) on each developer’s machine and the build server machine, and it will automatically appear as an option in the rule set dropdown.

Configuring the Build Definition

Next we need to configure the build definition:

1. Set the “Trigger” to “Gated Check-in”
   
   
2. Under “Process”, expand “Basic” and set “Perform Code Analysis” to “Always”
    
   

That’s it, now check-ins with code analysis warnings will be blocked for projects using the new custom rule set(s).

Hi Everyone,

With the launch of the Beta we would like to tell you about some of the great enhancements we have made to code analysis based on your feedback.  Back when we started planning for Visual Studio 11 we spent a good deal of time talking with people who use code analysis, and understanding the common pain points.  What we learned was there are three key areas you would like to see us improve:

1. Help better manage large numbers of warnings
2. Make the output from the analyzer more understandable
3. Improve the accuracy of the analyzer and the types of coding errors it finds

In this post let’s go over some of the highlights for code analysis in Visual Studio 11:

• Code Analysis is available in all editions of Visual Studio and supports 64bit C++ projects
• Custom rule sets for C++ projects and quick keyword filtering for managing results
• Ability to step through each line on the warning path to improve understanding of the issue
• More accurate, relevant warnings to find important bugs early in development

Code Analysis Available in All Editions of Visual Studio

First, we are really excited to announce that we are including code analysis in all editions of Visual Studio 11, including a subset of the most critical warnings in the Express edition for free (this applies to C++, C#, and VB code analysis) and all rules in the Professional, Premium, and Ultimate editions.  We see code analysis as an important tool for writing high quality software, and we want you to have access to the same tools that we run internally at Microsoft.

Filtering and C++ Rule Sets

Historically, one of the difficult things about using code analysis has been managing the sometimes large sets of results.  When we would run analysis on a moderate or large codebase for the first time the sheer number of warnings returned was overwhelming.  Finding ways to carve off small bits was difficult.

To help with this we have created a new window for managing Code Analysis results.

This window contains a keyword filter text box where you can filter code analysis results on warning number, text in the title or message of the warning, as well as filename or function name.  We have found this is really useful for quickly getting to the code analysis warnings that are most relevant.  For example, say you are adding a new function to an existing project that has previous code analysis warnings in it, and you just want to see any new warnings you may have added. Using keyword filtering you can filter on your new function name and investigate those first.

In addition, if you are using Visual Studio 11 Professional, Premium, or Ultimate editions you can now create custom rule sets for C++ projects.  The rule set configuration file determines which warnings Code Analysis checks for. We have included a default rule set that we think is a great place to start, but we encourage you to customize the rule set to make Code Analysis more relevant to you. For instance, if your organization cares about globalization defects because you ship your software in multiple languages you can enable these rules, or vice versa.

Detailed Explanation of Code Path to Warning

Another part of the C++ code analysis experience we set out to improve is around understanding how the analyzer found the problem.  Previously when investigating a code analysis warning we would often scratch our heads and say to ourselves “ok, it’s telling me there is a bug on this line of source code, but how did it get there in the first place?”

So in Visual Studio 11 we have introduced the concept of “key events.” A Key event is a relevant decision or assumption the analyzer made in the process of finding a defect. In the example below there are three key events (on the left). The key event on line 7 explains what the analyzer assumed in order to reach the bug; that the Boolean parameter ‘guard’ is false.

In the Code Analysis window you can click on a warning and step through these key events similar to a traditional debugger.

We have added key events to a handful of the most relevant and common C++ warnings, and as we hear feedback from you we will continue to update and improve the output of the warning messages.

Many Other Improvements

Lastly I would like to mention that there are many other improvements we have made to the accuracy of the C++ analyzer, the source code annotation language used by the analyzer (as well as documentation for it), and the kinds of defects the analyzer finds.  Just to point out one improvement; in this release we have added checks for concurrency defects like threading deadlocks and race conditions in C++ code.  However, these are topics unto themselves, so we can save them for another day.

In closing this first post for code analysis in Visual Studio 11, we are excited to use this blog as a way to teach, learn, and interact together.  We encourage you to download the Visual Studio 11 Beta and check out code analysis, and we appreciate and look forward to your feedback.

-Code Analysis Team

To discover more about code analysis in Visual Studio 11 go here:

http://msdn.microsoft.com/en-us/library/windows/apps/hh441471(v=VS.85).aspx

We are pleased to announce that we’ve released the next version of FxCop. This release has a number of changes since FxCop 1.36 Beta 2, including, but not limited to, the following:

• 
  
  Bug fixes that reduce noise, missing analysis and rule crashes.


• 
  
  New portability rule: Use Only API from Targeted Framework.  This rule will fire when the target assembly taking a dependency on a new API only included in a later version or in a service pack.




• 
  
  New option for new portability rule for selecting target framework for analysis.




• 
  
  Set the target framework in the UI via Project -> Option -> Spelling & Analysis -> Target Framework


• 
  
  Set the target framework on the command-line via the /targetframeworkversion switch. e.g: /targetframeworkversion:v2.0, /targetframeworkversion:v3.0, or /targetframeworkversion:v3.5

Compared with FxCop 1.35, FxCop 1.36 Beta 2 had changes including, but not limited to, the following:

• 
  
  200+ bug fixes that reduce noise, missing analysis and rule crashes


• 
  
  Support for analyzing anonymous methods and lambda expressions


• 
  
  New option for skipping analysis over tool generated code 




• 
  
  Turn this on in the UI via Project -> Options -> Spelling & Analysis -> Suppress analysis results against generated code


• 
  
  Turn this on on the command-line via the /ignoregeneratedcode switch. 


• 
  
  Better support for C++/CLI and the Compact Framework


• 
  
  Language ‘friendly’ API names in the UI and resolutions (ie Visual Basic syntax if running over a Visual Basic binary)


• 
  
  New globalization, design and usage rules


• 
  
  Performance improvements that cut analysis by 2x and use half as much memory


• 
  
  Documentation that is now available on MSDN

There are also some other underlying changes that we will talk about in some future posts. 

Download it, and tell us what you think. If you have any feedback, bug reports or any questions, feel free to head over to the Code Analysis forum and ask away.

Note:  If you already have FxCop 1.36 Beta 2 installed, please uninstall it first before you install FxCop 1.36. Otherwise, you may see an error when you install FxCop 1.36 on top of FxCop 1.36 Beta 2.

If you accidentally install FxCop 1.36 without uninstalling FxCop 1.36 Beta 2, please go to Add/Remove program to uninstall FxCop 1.36, and reinstall FxCop 1.36.

[EDIT] Note: FxCop 1.36 RTM shipped with additional tracing turned on.  This can make the FxCop output harder to read.  To turn tracing off, edit the FxCop.exe.config or FxCopCmd.exe.config files in the FxCop install directory.  Find the line that contains <add name=”Trace” value=”2″ /> and change the “2” to “0”.

I’ve just published a post over my blog about a new feature we added for Visual Studio 2008 SP1 and FxCop 1.36.

New for Visual Studio 2008 SP1 and FxCop 1.36 – Multi-targeting rule

Two weeks ago, I introduced you to Visual Studio 2010 September ’08 CTP (Community Technology Preview). This CTP is available as a Virtual PC (VPC) image which can be downloaded at http://go.microsoft.com/fwlink/?LinkId=129231. The goal of the Community Technology Preview is to obtain feedback from our customers on the new scenarios we have enabled.  If you haven’t already downloaded the CTP, do it now and take it out for a spin. 

There are many new cool features with the CTP such as an Historical Debugger and Impact Analysis of code changes, but today we are going to focus on Rule Sets for code analysis. (For an overview of all the neat stuff happening in code analysis, check out this PDC video http://mschnlnine.vo.llnwd.net/d1/pdc08/WMV-HQ/TL60.wmv )  Configuring code analysis in Visual Studio 2008 and earlier versions required evaluating each individual rule to determine whether it was important enough to turn on and fix for your project. This might be a very time-consuming process that made it difficult to make sure that the most important problems were identified and fixed. With rule sets, code analysis can now be configured much more quickly and easily with sets of rules that are targeted at specific scenarios or areas of emphasis. Let’s take a look at how this works.

The following scenario comes from our CTP walkthrough.  You can find the walkthrough and more details when you download the CTP as described above.  Let’s assume that you have the DinnerNow – Kiosk solution open and is the active project.  On the Analyze menu, click Configure Code Analysis for DinnerNow.Restaurants.Kiosk.  The property page for Code Analysis is displayed:

This screen tells us that Microsoft All Rules will be executed when we run code analysis, but what if we didn’t want to run every Microsoft rule?  What if we have a specific scenario we wish to target?  We can change which rule set to run by clicking on Open which brings up:

We can select which rule set(s) by simply selecting or deselecting the appropriate box.  Notice that each rule set has a brief description of the types of rules within the rule set.  Further, you can open up each individual rule set and see the specific rules that make up the rules sets.  You can also turn on or off individual rules within a rule set.  Finally, you can adjust the type of action a rule will trigger.  In the past, code analysis rules have been limited to build Warnings, but now you can elevate code analysis rules to build Errors.

As you can see, rules sets provide a powerful way to focus code analysis on the scenarios and rules that matter most to you.  You can also create custom rule sets based on your specific needs.  We wont go into it today, but if you download the CTP, the Walkthrough explains how to customize a rule set.

Give it a try and let us know what you think.

Cris

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

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.

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

• 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.

This blog compares the Code Analysis warnings and errors generated by Visual Studio 2008 and Visual Studio 2010.

Managed Code Analysis

FxCopCmd Errors

No changes between Visual Studio 2008 and Visual Studio 2010.

C/C++ Code Analysis

No changes between Visual Studio 2008 and Visual Studio 2010.

This blog explains how to implement your own static code analysis rules for analyzing your .NET (C#, VB.NET, etc) code. The material was written by Todd King, one of the developers on the Visual Studio Code Analysis team.

NOTE: Writing custom FxCop rules, the associated APIs and the process for installing them is not a supported feature of the product. We are providing this information because we get so many questions about how to do it.

Prerequisites

You must be using Visual Studio 2010 Premium or Visual Studio 2010 Ultimate to implement custom code analysis rules.

Creating the MyCustomRules project

NOTE: If you already have an existing custom rules project you can skip this step.

1. Create a new class library project and name it whatever you want your rules assembly to be named. For the purposes of this blog I’ve named it MyCustomRules.

2. Next add a reference to the FxCop assemblies. Your custom rules project will need to reference FxCopSdk.dll and Microsoft.Cci.dll. Visual Studio 2010 installs the assemblies in “C:\Program Files\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\FxCop” on a 32-bit OS and “C:\Program Files (x86)\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\FxCop” on a 64-bit OS. In order to avoid path resolution issues when the project is built on different computers you can use the $(CodeAnalysisPath) MSBuild property. The property will resolve to the location where the FxCop assemblies have been installed. Use the following procedure to define the references to the two assemblies

   1. Open up your project in Visual Studio 2010.

   2. In Solution Explorer right click on the project and select Unload Project

   3. Now right click on the project and select edit MyCustomRules.csproj

   4. Find the ItemGroup xml element where your project’s references are and add the first two <Reference> elements described in the following code snippet

      1. <ItemGroup>
      2.   <Reference Include="FxCopSdk">
      3.     <HintPath>$(CodeAnalysisPath)\FxCopSdk.dll</HintPath>
      4.     <Private>False</Private>
      5.   </Reference>
      6.   <Reference Include="Microsoft.Cci">
      7.     <HintPath>$(CodeAnalysisPath)\Microsoft.Cci.dll</HintPath>
      8.     <Private>False</Private>
      9.   </Reference>
      10.   <Reference Include="System" />
      11.   <Reference Include="System.Core" />
      12.   <Reference Include="System.Xml.Linq" />
      13.   <Reference Include="System.Data.DataSetExtensions" />
      14.   <Reference Include="Microsoft.CSharp" />
      15.   <Reference Include="System.Data" />
      16.   <Reference Include="System.Xml" />
      17. </ItemGroup>

   5. Close the editor, right click on the project and select Reload Project.

3. Now we need to setup the RuleMetadata.xml file for this project. The RuleMetadata.xml file is where various properties of the rules for this project will be stored. For example this is where the rule description, resolutions, message level, owner contact info, etc is stored.

   1. To Add a RuleMetadata.xml file right click on your project and select add new item.

      1. Type XML File in the Search Installed Templates control.

      2. Select the XML File template and name it RuleMetadata.xml (it can be named whatever you want, for the purposes of this blog I’ve named it RuleMetadata.xml).

   2. At this point you don’t have any rules so all you need to do is add a root Rules element as follows. Where the FriendlyName value is some user readable string that will be displayed to the user as the name of your rules assembly.

      1. <?xml version="1.0" encoding="utf-8" ?>
      2. <Rules FriendlyName="My Custom FxCop Rules">

4. Next set the RuleMetadata.xml file as an EmbeddedResource for our rules assembly

   1. In Solution Explorer right click on the file RuleMetadata.xml and select Properties

   2. In the Property Tool window change the Build Action property to Embedded Resource.

Implementing a custom rule

Note that we have not released an SDK for implementing custom rules, so the API is undocumented and will almost certainly change in the future. With those caveats in mind, the following example describes how to implement a simple rule. The rule we will implement checks whether or not the identifiers for private and internal fields use Hungarian notation.

1. Define an abstract class that inherits from the FxCop API and initializes the resources defined in the XML file.

1. using Microsoft.FxCop.Sdk;
2.  
3. namespace MyCustomFxCopRules
4. {
5.     
6.     internal abstract class BaseFxCopRule : BaseIntrospectionRule
7.     {
8.         protected BaseFxCopRule(string ruleName)
9.             : base(ruleName, "DukesFirstFxCopRule.DukesFirstFxCopRule", typeof(BaseFxCopRule).Assembly)
10.         { }
11.     }
12.  
13. }

Where the resource name is the default namespace of your project + whatever you named the RuleMetadata.xml file. "MyCustomFxCopRules.RuleMetadata" in the example above.

NOTE: Make sure you use the default namespace for your project in the resource name. If you do not FxCopCmd.exe will return error CA0054 because it is unable to load your rule.

2. Define a class to implement the rule and derive from our previously defined class.

1. internal sealed class EnforceHungarianNotation : BaseFxCopRule
2. {
3.     public EnforceHungarianNotation()
4.         : base("EnforceHungarianNotation")
5.     { }
6. }

3. Define the visibility of the code elements we want to analyze by overriding the TargetVisibility property. Normally it is fine to leave this at the default implementation of TargetVisibilities.All however in this case we only want to analyze fields that are not externally visible so we want to return a value of TargetVisibilities.NotExternallyVisible. Add the following code to the EnforceHungarianNotation class definition.

1. // Only fire on non-externally visible code elements.
2. public override TargetVisibilities TargetVisibility
3. {
4.     get
5.     {
6.         return TargetVisibilities.NotExternallyVisible;
7.     }
8. }

4. Since this rule is supposed to fire on fields, which are members of types, we override the Check(Member) method. We need to verify that the member being examined by the check method is actually a field. This could be done either by trying to cast it to a Microsoft.FxCop.Sdk.Field type or checking if the member’s NodeType is NodeType.Field. Once we know we are looking at a field we need to determine if it is a static field or not so we know which kind of Hungarian prefix should be expected. To do this we can check the IsStatic property on the field. Now we just need to determine if the field’s name starts with the expected Hungarian notation prefix and if not report a rule violation. To do this we get the field’s name using the Name property (actually need to call Name.Name to get the string form of the name, just one of the quirks of the current API) and check if it starts with the expected prefix. If not then we need to construct a Problem object and add it to the rule’s ProblemCollection accessed through the inherited Problems property. Add the following code to the EnforceHungarianNotation class definition.

1. public override ProblemCollection Check(Member member)
2. {
3.     Field field = member as Field;
4.     if (field == null)
5.     {
6.         // This rule only applies to fields.
7.         // Return a null ProblemCollection so no violations are reported for this member.
8.         return null;
9.     }
10.  
11.     if (field.IsStatic)
12.     {
13.         CheckFieldName(field, s_staticFieldPrefix);
14.     }
15.     else
16.     {
17.         CheckFieldName(field, s_nonStaticFieldPrefix);
18.     }
19.  
20.     // By default the Problems collection is empty so no violations will be reported
21.     // unless CheckFieldName found and added a problem.
22.     return Problems;
23. }
24. private const string s_staticFieldPrefix = "s_";
25. private const string s_nonStaticFieldPrefix = "m_";

5. Rule resolutions are stored in the RuleMetadata.xml file. Calling GetResolution will retrieve that resolution string and also fill in any string arguments passed in. Finally we need to create a Problem object from the Resolution object we just created and add that Problem to the Problems collection for this rule. Add the following code to the EnforceHungarianNotation class definition.

1. private void CheckFieldName(Field field, string expectedPrefix)
2. {
3.     if (!field.Name.Name.StartsWith(expectedPrefix, StringComparison.Ordinal))
4.     {
5.         Resolution resolution = GetResolution(
6.           field,  // Field {0} is not in Hungarian notation.
7.           expectedPrefix  // Field name should be prefixed with {1}.
8.           );
9.         Problem problem = new Problem(resolution);
10.         Problems.Add(problem);
11.     }
12. }

6. The final step is adding the appropriate rule metadata for this new rule to the RuleMetadata.xml file in our project. The following rule metadata can be defined in the RuleMetadata file.

• Display name of the rule.
• Rule description.
• One or more rule resolutions.
• The MessageLevel (severity) of the rule. This can be set to one of the following:
  • CriticalError
  • Error
  • CriticalWarning
  • Warning
  • Information
• The certainty of the violation. This field represents the accuracy percentage of the rule. In other words this field describes the rule author’s confidence in how accurate this rule is.
• The FixCategory of this rule. This field describes if fixing this rule would require a breaking change, ie a change that could break other assemblies referencing the one being analyzed.
• The help url for this rule.
• The name of the owner of this rule.
• The support email to contact about this rule.

For the example EnforceHungarianNotation rule described in this sample the RuleMetadata.xml file should look something like:

1. <?xml version="1.0" encoding="utf-8" ?>
2. <Rules FriendlyName="My Custom FxCop Rules">
3.   <Rule TypeName="EnforceHungarianNotation" Category="MyRules" CheckId="CR1000">
4.     <Name>Enforce Hungarian Notation</Name>
5.     <Description>Checks fields for compliance with Hungarian notation.</Description>
6.     <Resolution>Field {0} is not in Hungarian notation. Field name should be prefixed with '{1}'.</Resolution>
7.     <MessageLevel Certainty="100">Warning</MessageLevel>
8.     <FixCategories>NonBreaking</FixCategories>
9.     <Url />
10.     <Owner />
11.     <Email />
12.   </Rule>
13. </Rules>

NOTE: The TypeName attribute of the Rule element must match exactly with the name string passed in to the base constructor of the rule implementation. If they do not match FxCopCmd.exe will return error CA0054 because it is unable to load your rule.

Debugging custom rules

You can debug custom rules through FxCopCmd.exe. Normally you would run your rule against another project. To simplify the instructions in this blog we’re going to run our new rule against the implementation of the rule itself. In the project properties for your custom rules project on the Debug tab do the following

1. Configure the project to launch an external program and enter in the path to FxCopCmd.exe. For example
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\FxCop\FxCopCmd.exe

2. For command line arguments specify
/out:"results.xml" /file:"MyCustomRules.dll" /rule:"MyCustomRules.dll" /D:"C:\Program Files (x86)\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\FxCop"

3. Set the working directory to the build output folder. For example
C:\Projects\MyCustomRules\MyCustomRules\bin\Debug\

Now you can to debug your custom rules by simply hitting F5 from your custom rules project. Try it

1. Set a breakpoint on the statement

1. if (!field.Name.Name.StartsWith(expectedPrefix, StringComparison.Ordinal))

2. Press F5 and execution should stop at the breakpoint.

3. Press F5 again and execution should complete successfully.

4. Note that there is not a results.xml file in the …\Debug folder because there are no rule violations in the code we are running the rule against.

Let’s create a rule violation so we can verify that our rule is behaving as it should.

1. Add the following code to the EnforceHungarianNotation class definition

1. private static int m_Foo;

2. Press F5

3. Disable the breakpoint and Press F5 again

4. Examine the results.xml file in the …\Debug folder. Note the description of the rule violation. It works!

Running custom rules

At this point we have verified that our rule functions as expected. To run our custom rule using the command line utility FxCopCmd simply use the command line options we defined in the Debug options. Run FxCopCmd.exe /? For a list of all the command line utility’s options.

A new feature in Visual Studio 2010 is called rule sets. Rule sets are a new way of configuring which rules should be run during analysis. The easiest way to integrate your rules into Visual Studio 2010 is to copy them to the %Program Files%\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\FxCop\Rules directory. If you are replacing an existing assembly you will need to restart Visual Studio after copying the file. Once the file is copied to the Rules directory the next time you launch the rule set editor you should see your custom rules. Try the following procedure

1. From your project’s property settings select the Code Analysis tab

2. Click on the Open button to open the Rule Set editor

3. Create a custom rule set by doing a File à Save As and saving the rule set to MyCustomRuleSet.ruleset

4. Click on the button Show rules that are not enabled in the rule set editor’s button bar. Your custom rule(s) should appear in the list.

If you don’t want to mess with your Visual Studio installation by adding your own custom rules to the built in Rules directory that Visual Studio uses, you can manually edit a custom rule set instead.

1. Create a new rule set and save it.

2. Open that new rule set file in a text or xml editor and add a RuleHintPaths section with a Path element with the location of your custom rules. The path to your custom rules can include absolute file paths, relative paths, and use environment variables. For example your rule set file might look like the following:

1. <?xml version="1.0" encoding="utf-8"?>
2. <RuleSet Name="My Custom Rule Set" Description=" " ToolsVersion="10.0">
3.   <RuleHintPaths>
4.     <Path>%CustomRulesPath%</Path>
5.     <Path>..\..\CustomRules</Path>
6.     <Path>C:\CustomRules</Path>
7.   </RuleHintPaths>
8. </RuleSet>

3. Now open that rule set file with the visual studio Code Analysis Rule Set Editor (the default editor for *.ruleset files). Your custom rules should appear in the editor as seen above.

Troubleshooting Visual Studio integration

If code analysis is reporting errors performing analysis due to exceptions, more details on those exceptions can be found in the *.CodeAnalysisLog.xml file in the bin directory of the assembly being analyzed (see the Exceptions section of the report file towards the bottom).

When you run code analysis from Visual Studio the FxCopCmd command line utility is invoked to perform the analysis. To discover exactly what command line options are being passed to FxCopCmd by Visual Studio so you can reproduce and debug the error outside of Visual Studio, first set the build output verbosity to Normal or higher. This can be done by going to Tools – >Options -> Projects and Solutions -> Build and Run.

Run code analysis and view the output window. You should see the exact command line arguments passed into FxCopCmd right after the “Running Code Analysis…” message.

For more information on where FxCopCmd is looking for assemblies you may increase the trace level of FxCopCmd to 3. This can be done by modifying the FxCopCmd.exe.config file in the same directory as FxCopCmd.exe as follows

1.  
2. <switches>
3.   <!–
4.         TraceSwitch has the following values
5.           Off = 0, Error = 1, Warning = 2, Info = 3, Verbose = 4
6.                   
7.         BooleanSwitch has the following values
8.           Off = 0, On = 1        
9.       –>
10.  
11.   <!– TraceSwitch'es –>
12.   <add name="Trace" value="3" />
13.  
14.   <!– BooleanSwitch'es –>
15.   <add name="TraceExceptions" value="0" />
16. </switches>

Once this is done the xml reports (like the *.CodeAnalysisLog.xml file mentioned earlier) produced by FxCopCmd will contain a DebugInfo section that details what search paths FxCopCmd used and exactly where it resolved each assembly reference to. This information can also be determined by examining the trace messages emitted by FxCopCmd to the console.

This blog post applies to Visual Studio 2010 Premium and Ultimate editions. The content was written by Kevin Blasko one of the developers on the Visual Studio Code Analysis team.

The purpose of this blog post is to give you some background on the implementation of the Dataflow Analysis (DFA) rules in Visual Studio 2010.

New Engine, New Rules for Visual Studio 2010

If you looked at the What’s New in Visual Studio 2010 Blog Post you will have noticed that there are several new Code Analysis rules for Managed Code. Several of these new rules are what we describe as DFA rules. These rules are implemented using the Phoenix Code Analysis engine. The rules are:

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

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

This list of rules should give you an idea of what a DFA engine is capable of.

Why Implement A New Code Analysis Engine?

We needed to implement a new analysis engine to improve the quality and performance of DFA rules. We chose to do this using a technology developed by Microsoft Research called Phoenix. Phoenix is an extensible compiler framework with advanced analysis capabilities. Static analysis turns out to be very important to compilers since the more information you have about the state of the program, the better optimizations you can make when compiling the program. We took advantage of the existing analysis infrastructure as a starting point and built our new engine on top of it. The engine is capable of producing better quality analysis with less noise, less missed analysis, and better performance than our previous DFA engine.

The Phoenix engine excels at analyzing function bodies. Whereas the engine used for the rest of the managed code rules is good at symbolic analysis of class and function definitions (which the Phoenix engine can do as well). For example, consider the following simple example that is actually difficult to analyze without an engine with Phoenix’s capabilities. For the sample, assume that we’re trying to detect violations of CA1062 Validate Arguments of Public Methods.