Code Analysis Team Blog : Tips and Tricks

Fun with Code Analysis Rule Sets

cristend — Wed, 12 Nov 2008 22:55:00 GMT

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

Reporting Code Analysis Defect Counts

conorm — Wed, 02 Jan 2008 23:10:06 GMT

Code analysis defect counts are available in the cube that is part of the TFS Data Warehouse. This post shows you how to hook up Excel to show code analysis counts in a pivot table.

First off you need to connect Excel up to the data warehouse that has the data. Under the Data tab in Excel select From Other Sources, From Analysis Services.

Then you need to give the name of the server with the data warehouse. In the standalone TFS case this will be whatever machine is running TFS. Assuming you have read permissions with your Windows account you can click Next, otherwise enter a user name and password that has access to the server and click Next.

Then, select the database (usually TfsWarehouse) and select the Build table.

Click Next and then supply whatever additional information that will help you remember this data connection.

Click Finish. Then define how you want to show the data in Excel - e.g. a pivot table.

Click OK which gives you the following:

In the PivotTable Field List, Expand Build Project where you will find two fields: Static Analysis Errors and Static Analysis Warnings:

You can click the checkboxes to add these to the values for your table. In most cases Static Analysis Warnings would be the most useful since Static Analysis Errors would typically stop the build.

To complete the picture you can play with the pivot table and pivot and filter as you see fit. As a simple example you can add the Build field:

Which will give you one row per build in the pivot table.

Of course this data can be combined with other build data and charted etc. according to your needs. We are considering what reporting to provide in future versions so would love to hear your feedback on this feature and what you would like to see.

TIP: How to change the (Orcas) Managed Code Analysis naming/design rules to fire on internals

David M. Kean — Tue, 08 May 2007 18:00:00 GMT

A while ago I mentioned that FxCop (and hence Managed Code Analysis) naming and design rules only fire on publicly visible types and members.

As you may recall, there were a couple of reason for this:

The .NET Framework Design Guidelines, which FxCop/Managed Code Analysis enforces, only contains guidelines for publicly visible API. What internal Microsoft teams (and you) do with their internal types and members is completely up to them.
Noise. If you tend to wrap a lot of native types and members, then this internal API could be potentially fire numerous violations.

In that same post, I also showed how to override this behavior in in FxCop. Now, since then, I've been asked by a few readers on whether it was possible to do this within Visual Studio 2005, unfortunately, the answer up until now was no.

However, the good news is that in the newly released Visual Studio 'Orcas' Beta 1, we sneaked in a small feature in that allows you to override this on a per-project basis.

To turn it on, simply do the following:

Using Visual Studio, open your project
In Solution Explorer, right-click the project and choose Unload Project, answering Yes to any prompt to save changes
In Solution Explorer, right-click the project and choose Edit

Under the first <PropertyGroup> element, add a new <CodeAnalysisOverrideRuleVisibilities> element with its value set to true:

In Solution Explorer, right-click the project and choose Reload Project, answering Yes to both prompts

The naming and design rules (such as IdentifiersShouldBeCasedCorrectly and IdentifiersShouldBeSpelledCorrectly) will now run against all types and members, not just those visible outside of the assembly.

If you want to enable this for all your projects, see the following: FAQ: How do I share Managed Code Analysis rule settings over multiple projects?.

TIP: Scope the Code Analysis Policy to apply to specific source control paths/file types

ravkaur — Tue, 30 Jan 2007 19:00:00 GMT

On the forums, we have had posts from customers who want to customize their code analysis policy to skip certain file types such as .sql, docs etc. This is because the policy will block checkins even though code analysis doesn’t apply to those files.[ See thread: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1080300&SiteID=1 ] There is now a way to configure code analysis policy to apply to specific source control paths/file types. Check out the tool on gotdotnet that helps you to do so. http://www.gotdotnet.com/codegallery/codegallery.aspx?id=96d7da50-0d61-4230-9af9-49684ae9881e

Here's what you need to do (Part of the steps are also in the readme for the custom path policy)

a) Download the custom code analysis policy from the location specified on the link. This is a project and you will need to build it.

b) Launch Regedit (or any other registry editor of choice), and navigate to the following key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\TeamFoundation\SourceControl\Checkin Policies

c) Add a string value called "CustomPathPolicy" – set the value to the path where the DLL is located, such as: C:\SD_TIDM\Technical Integration\CustomPathPolicy\Extensibility\bin\Debug\CustomPathPolicy.dll

Once the registry key is set up, follow these steps to set up the custom policy.

Add code analysis policy to the team project via Team Project Settings -> Source Control -> Check in Policy
Click "Add" again and select "Custom Path Filter" item, which will invoke the Edit dialog.
From the dropdown, select 'Code Analysis'
Enter the regex path filters to which the policy should apply to, click add, repeat as needed.
Click OK to save the settings.
Disable the original code analysis policy set in step 1). If this is not done, the policy will be evaluated twice.

Once you have this set up, the code analysis policy will apply to only paths that you have specified. One thing to keep in mind is that migrating code analysis settings to solution does not respect the paths set in the custom path policy. i.e. Migrating code analysis policy settings to solution will migrate to all projects within the solution, not just the ones specified in the custom path policy.

TIP: Automatically generate Managed Code Analysis/FxCop suppressions

David M. Kean — Thu, 18 Jan 2007 19:00:00 GMT

I see a lot of users attempting to hand code a SuppressMessageAttribute themselves. This can be error prone and is not needed when both Visual Studio and the standalone FxCop can automatically generate these for you.

In Visual Studio 2005

Right-click a Code Analysis warning in the Error List and choose Suppress Message(s).

In Visual Studio Orcas

Right-click a Code Analysis warning in the Error List and choose Suppress Message(s) -> In Source or Suppress Message(s) -> In Project Suppression File

In FxCop

Right-click a warning and choose Copy As -> SuppressMessage.
Paste the contents of the Clipboard at the top of the code element that caused the warning.

Note: In both Visual Studio and FxCop you can select multiple warnings and suppress them all once.

TIP: How to quickly enable Code Analysis on multiple projects [David Kean]

David M. Kean — Fri, 11 Aug 2006 18:00:00 GMT

Daniel Fisher has posted a entry on using a macro to quickly enable Code Analysis on multiple projects. The macro also allows you to apply the same rule selections across an entire solution.

Thanks Daniel!

TIP: How to change the FxCop naming/design rules to fire on internals [David Kean]

David M. Kean — Wed, 09 Aug 2006 06:56:00 GMT

By default, the FxCop naming and design rules only fire on publicly visible types and members. There are a couple reasons for this:

The .NET Framework Design Guidelines, which FxCop enforces, only contains guidelines for publicly visible API. What internal Microsoft teams (and you) do with their internal types and members is completely up to them.
Noise. If you tend to wrap a lot of native types and members, then this internal API could be potentially fire numerous violations.

However, if you would feel like you would like to be consistent with both your internal and customer facing API, then a little known feature is the ability to override this default in FxCop.

To do this, simply do the following:

Using FxCop, open your FxCop project
Choose Project -> Options
Choose the Spelling & Analysis tab and check Run all overridable rules against all targets
Click OK

Unfortunately, it is not possible to currently change this in Visual Studio Code Analysis.

TIP: Get more information about a rule/warning within Visual Studio [David Kean]

David M. Kean — Tue, 13 Jun 2006 08:53:00 GMT

Did you know you can get more information about a particular rule/warning within Visual Studio; including its description, information on how to fix it, whether or not it is considered a breaking change, when or when not to suppress it and code samples?

To do this for a particular warning in the Error List:

Right-click the warning and choose Show Error Help

-or-

Select the warning and press F1

To do this for a particular rule:

In Solution Explorer, right-click your project and choose Properties
In the Project Properties window, choose the Code Analysis tab
Expand one of the category nodes, select a rule node and press F1

This information is updated regularly, so you can make sure the Help viewer always displays the most update-to-date information by changing it so that it tries the online MSDN Library version before the local:

Choose Tools -> Options
In the Options dialog, expand to and select the Environment -> Help -> Online node
Under When loading Help content, choose Try online first, then local and click OK