Code Analysis Team Blog : tsbt-dev

David Kean's new blog

David M. Kean — Tue, 10 Jun 2008 17:00:00 GMT

For those that are interested, I've just started a new personal blog, Dave's Box, where I will be talking about FxCop, Framework Design Guidelines, and the recently announced Managed Extensibility Framework.

I've just posted a couple of posts detailing changes we made to FxCop 1.36:

FxCop now ships with the spell checker libraries
Reference resolution changes in Code Analysis and FxCop

You can subscribe via the one of the two following links:

Subscribe via reader
Subscribe via email

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.

Come chat with the Code Analysis team tomorrow

David M. Kean — Tue, 04 Dec 2007 20:16:00 GMT

Join members of the Visual Studio Team System product group to discuss features available in Team Foundation Server, Team Suite, Architecture Edition, Development Edition, Database Edition, and Test Edition. In addition, discuss what's new for these editions for Visual Studio 2008.

We will be holding two sessions:

Join the chat on Wednesday, December 5th, 2007 from 10:00am - 11:00am Pacific Time. Add to Calendar | Additional Time Zones

-and-

Join the chat on Wednesday, December 5th, 2007 from 4:00pm - 5:00pm Pacific Time. Add to Calendar | Additional Time Zones

Try the Code Analysis Rule Sets Feature in the November "Rosario" November 2007 CTP

conorm — Thu, 29 Nov 2007 01:52:00 GMT

We have a great new feature that we are previewing in Microsoft® Visual Studio® Team System code name “Rosario” November 2007 CTP. This feature allows you to select pre-defined sets of rules to configure code analysis as well as define your own. To access this feature right click on a project and choose "Properties" then click on the "Code Analysis" tab.

This feature is in response to the feedback we received that the number of rules is overwhelming and difficult to configure.

For this preview release we have focused on the core concept and made minimal changes to the UI. In RTM we will have a new UI and a rich edit experience. This release is all about getting your feedback. Try out this feature on your code, use the built-in rule sets and let us know what you think. Tell us what we missed or what rules you think are there and should not be. Your real-life experience is our best guide for this feature.

You can create a custom rule set to fine tune the exact rules to use. If you think we should include your custom rule set in the out of the box sets then we want to hear from you (feedback links below). Just attach the exported file to your connect bug or mail us.

Some useful links:

Release Post from JeffBe and download instructions - here
Feedback - bugs and suggestions can be submitted via http://connect.microsoft.com/visualstudio. Make sure when you submit issues through Connect that you indicate the product version as being “Visual Studio Team System Code Name “Rosario” (November 2007 CTP)”. That will ensure it gets to the right folks for consideration.
Questions - we’ve created a special forum specifically focused on Rosario: http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=1736&SiteID=1 or you can respond to this blog post.

We look forward to hearing from you and hope you enjoy this new feature.

Positioning Code Metrics to Management

conorm — Thu, 29 Nov 2007 01:08:08 GMT

Another question that is coming up is:

How can (or should) code metrics be presented to management ?

My view is that in all cases the metrics are something that can help make decisions around focus and prioritization. Management should be made aware of the metrics and what they mean to allow them to decide where to focus resources. If management is more levels away from the code then the Maintainability index can serve as a good, simple, metric.

Sometimes you may ship code that has low maintainability or very high complexity etc. and management would make this decision based on risk, time and resources and perhaps other factors. Metrics helps them make that decision with quantitative data.

Some possible options:

One option is to present the metrics in terms of risk and mitigation. For example:
1. Risk: low maintainability in some module
2. Mitigation: the module is reviewed.
3. Risk: High cyclomatic complexity
4. Mitigation: the module has a high number of test cases.
Another option is to evaluate the metrics on legacy code. This could be to select some code that is known to have lots of issues and then run the metrics on the code to see if metrics would report any issues with the code. This could be a good way to show value to management in the metrics themselves and make them case for them as a future preventative measure.
Yet another option is to present a trend over time. Unfortunately the tool doesn't currently make this very easy but at each milestone of the project you can record the maintainability and other metrics for the modules. This could then be compared across time and used in future planning or to guide management in allocating time and resources to particular parts of the project that are trending badly.

I'd be very interested in hearing other approaches people have taken in presenting metrics or code analysis in general to management.

Maintainability Index Range and Meaning

conorm — Tue, 20 Nov 2007 19:43:00 GMT

Another question:

The maintainability index has been re-set to lie between 0 and 100. How and why was this done?

The metric originally was calculated as follows (based on the work in Carnegie Mellon University although we modified the Halstead Volume calculation a little since we don't include comments anywhere in our calculation): Maintainability Index = 171 - 5.2 * ln(Halstead Volume) - 0.23 * (Cyclomatic Complexity) - 16.2 * ln(Lines of Code)

This meant that it ranged from 171 to an unbounded negative number. We noticed that as code tended toward 0 it was clearly hard to maintain code and the difference between code at 0 and some negative value was not useful. I'll post some tech ed sample code showing very low maintainability or you can try on your own code to verify. As a result of the decreasing usefulness of the negative numbers and a desire to keep the metric as clear as possible we decided to treat all 0 or less indexes as 0 and then re-base the 171 or less range to be from 0 to 100. Thus, the formula we use is:

Maintainability Index = MAX(0,(171 - 5.2 * ln(Halstead Volume) - 0.23 * (Cyclomatic Complexity) - 16.2 * ln(Lines of Code))*100 / 171)

On top of that we decided to be conservative with the thresholds. The desire was that if the index showed red then we would be saying with a high degree of confidence that there was an issue with the code. This gave us the following thresholds (as mentioned in this blog previously):

For the thresholds we decided to break down this 0-100 range 80-20 so that we kept the noise level low and only flagged code that was really suspicious. We have:

0-9 = Red
10-19 = Yellow
20-100 = Green

Code Metrics as Check-in Policy

conorm — Fri, 16 Nov 2007 10:39:00 GMT

This is the first in a series of posts around questions I am getting asked related to code metrics.

One question that is coming up is:

Can a check-in policy be defined based on code metrics in TFS?

Well, code metrics itself does not have a check-in policy but fortunately the Maintainability Index, Class Coupling, Depth of Inheritance and Complexity metrics are all available as rules in Code Analysis in Visual Studio. This means you can use code analysis check-in policy enabled with those rules. The rules are grouped under the "Maintainability Rules" Category and are configured as follows:

Metric	Corresponding Rule	Threshold
Depth of Inheritance	CA1501 AvoidExcessiveInheritance	Warning at above 5 levels deep
Complexity	CA1502 AvoidExcessiveComplexity	Warning at above 25
Maintainability Index	CA1505 AvoidUnmaintainableCode	Warning at below 20
Class Coupling	CA1506 AvoidExcessiveClassCoupling	Warning at above 80 for class and above 30 for a method

In the policy editor this would look like the following:

This allows you to enforce that code meets these thresholds before check-in. In future we are looking in to allowing the threshold values to be changed.

Code Metrics Customization

conorm — Fri, 16 Nov 2007 02:54:22 GMT

A number of people have asked:

Is there a way to customize the existing code metrics or add additional ones?

The simple answer at this time is No. There are no extension points or customizations available at this time for code metrics. This feature was added late in the cycle for VS 2008 and we were out of time to design and add the required hooks. We will use this release to gather feedback about the sorts of extensions you want.

To that end please feel free to respond to this post with information about any customizations or additional metrics that would be of interest to you. This will help us a lot in our future planning.

New for Visual Studio 2008 - Code Metrics

David M. Kean — Wed, 03 Oct 2007 17:00:00 GMT

While we've already briefly spoken about Code Metrics when we announced it, I thought I would discuss it in a little more depth, in particular the metrics it provides.

As mentioned previously, Code Metrics is a new tool window that helps users find and act upon complex and unmaintainable areas within an application.

The following shows the results of running Code Metrics over a fictional business application:

As you can see from above, for Visual Studio 2008, we're providing five metrics. These are detailed below.

Class Coupling

At each level, this indicates the total number of dependencies that the item has on other types. This number excludes primitive and built-in types such as Int32, String and Object. The higher this number, the more likely changes in other types will ripple though this item. A lower value at the type level can indicate candidates for possible reuse.

The following shows how coupling is calculated:

For example, as you can see above, Account is coupled to two other types, Address and Order, whereas Country is not dependent on any other type.

Depth of Inheritance

At the type level, depth of inheritance indicates the number of types that are above the type in the inheritance tree. For example, a type that derives directly from Object would have a depth of inheritance of 1. At the namespace and project level, this indicates the highest depth of inheritance of all the types contained within it. This number does not take into consideration the depth of any implemented interfaces. Deep inheritance trees can indicate an over-engineering of a problem and can increase the complexity of testing and maintaining an application.

The following shows how depth is calculated:

For example, in the above inheritance hierarchy, ListControl and Label have a depth of inheritance of 3, whereas Component has a depth of inheritance of 1.

Cyclomatic Complexity

At each level, this measures the total number of individual paths through the code. This is basically calculated by counting the number of decision points (such as if blocks, switch cases, and do, while, foreach and for loops) and adding 1. This number is also a good indication on the number of unit tests it will take to achieve full line coverage. Lower is typically better.

The following shows how complexity is calculated:

Lines of Code

At each level, this is a measure of the total number of executable lines of code. This excludes white space, comments, braces and the declarations of members, types and namespaces themselves. Lower is typically better.

The following shows how the lines are calculated:

Maintainability Index

At the member and type level, this is an index from 0 to 100 indicating the overall maintainability of the member or type. At the namespace and assembly level, this is an average of the maintainability index of all types contained within it. This index is based on several other metrics, including Halstead Volume (which factors in the number and use of operands and operators), Cyclomatic Complexity and Lines of Code. A low number indicates code that is complex and hard to maintain.

The Maintainability Index column also includes a icon that gives a quick indication as to the overall maintainability and complexity of a particular item. The following table shows the range at which an icon is shown:

Icon	Level	Range
	High Maintainability	Between 20 and 100 inclusive
	Moderate Maintainability	Between 10 and 19 inclusive
	Low Maintainability	Between 0 and 9 inclusive

These icons allow you to see at a glance any trouble spots that you should start to focusing on or filling bugs against.

Conclusion

Now that you know what these metrics measure, and how they are calculated, the next thing you'll want to know is what you should do when you start to see some red in your application. In a future post, I will cover why should should care about each metric, and how to go about fixing some of the common issues that cause particular metrics to high (or low in the case of Maintainability Index).

New for Visual Studio 2008 - The 'Analyze' menu

David M. Kean — Sat, 22 Sep 2007 17:00:00 GMT

While Ian Huff has already talked about the new 'Developer' menu that has been added to Visual Studio 2008, I thought I would briefly mention some of the changes to it that were made between Beta 2 and RTM.

For those that have yet to see this menu, similar to the existing Test menu, we've added a new top-level menu that will contain the Code Analysis, Code Metrics and Profiling menu items. This was done for discoverability reasons, and something we hope to leverage moving forward towards Rosario.

A quick rundown on some of the things that have changed since Beta 2:

Renamed the menu itself from the very non-specific Developer to the little bit more descriptive Analyze.
Removed the Code Analysis and Code Metrics sub menus and pulled their associated menu items up one level.
Pulled New Diff Report up one level and renamed it to Compare Performance Reports...
Renamed the Code Metrics and Code Analysis menu items:
Generate Code Metrics -> Calculate Code Metrics.
Migrate Code Analysis Policy Settings to Solution -> Code Analysis Settings for Solution.
Replace Code Analysis Settings with Code Analysis Policy Settings -> Replace with Check-in Policy
Add Code Analysis Policy Settings to Code Analysis Settings -> Merge with Check-in Policy

I probably don't have to tell that these changes, that we made to increase the usability of the menu, are great improvements, especially the renaming of probably what would have been in the running for the longest menu item in Visual Studio; Replace Code Analysis Settings with Code Analysis Policy Settings.

While a very small addition to Visual Studio 2008, we hope the new Analyze menu helps improve your workflow when working with the Code Analysis and Profiler features.

New for Visual Studio 2008 - Support for anonymous methods and lambda expressions

David M. Kean — Fri, 21 Sep 2007 17:00:00 GMT

One of my favorite new features for Code Analysis in Visual Studio 2008 is our support for analyzing anonymous methods and lambda expressions. While anonymous methods have been around in C# since Visual Studio 2005, lambda expressions are new for both C# and Visual Basic in Visual Studio 2008.

For those that are already familiar with the concept of anonymous methods (if not check out this article), lambda expressions provide a simpler, more concise syntax for writing inline methods. They also serve as the underpinnings of Linq.

Take the following code written in Visual Studio 2005 which converts a list of strings to uppercase, for example:

   internal static class StringFormatter
    {
        public static List<string> ToUpper(List<string> values, CultureInfo culture)
        {
            return values.ConvertAll(delegate(string value)
            {
                return value.ToUpper(culture);
            });
        }
    }

Using the new lambda syntax, the equivalent can be written in C# and Visual Basic like so:

        internal static class StringFormatter
    {
        public static List<string> ToUpper(List<string> values, CultureInfo culture)
        {
            return values.ConvertAll(value => value.ToUpper(culture));
        }
    }

   Friend Module StringFormatter

        Public Function ToUpper(ByVal values As List(Of String), ByVal culture As CultureInfo) As List(Of String)

            Return values.ConvertAll(Function(value) value.ToUpper(culture))

        End Function

    End Module

To understand how lambda expressions and anonymous methods are implemented underneath in IL (which is important for a tool like Code Analysis that runs over the binary and not the source), see the great in-depth posts by Raymond Chen for C# (Parts 1, 2, and 3) and Jared Parsons for Visual Basic (Parts 1, 2, 3, 4 and 5). Once you've read those posts, you'll understand why Code Analysis didn't get support for this for free.

What does this mean for Code Analysis users? Well, previously, in Visual Studio 2005, the engine would simply skip over these constructs and the user wouldn't find out about any violations, if any, contained within them. The good news is that we will now analyze them. The bad news is that any project making heavy use of anonymous methods is likely no longer Code Analysis clean on its upgrade to Visual Studio 2008. ;)

For a little more information on Code Analysis's support of anonymous methods, see the following topic: Anonymous Methods and Code Analysis (code formatting to be fixed for RTM).

Note: These is a bug in Beta 2 that prevents Code Analysis from analyzing lambdas/anonymous methods that access any locals or parameters outside of its own scope. This will be fixed in RTM of Visual Studio 2008.

New for Visual Studio 2008 - Code Analysis Policy improvements

David M. Kean — Thu, 20 Sep 2007 17:00:00 GMT

One not very well known feature that lights up when connected to a Team Foundation Server, is the ability to enforce that Code Analysis be run before every check-in. Called a Code Analysis Policy, this feature allows your team to find and fix Code Analysis warnings earlier in the product cycle rather than later, where code changes are riskier and more expensive to make.

To add a Code Analysis Policy to a Team Project, see the following topic on the MSDN Library, How to: Add Check-In Policies.

In Visual Studio 2005, while a useful feature, there were a few usability issues that customers ran into time and time again:

Migrating the Code Analysis settings stored in the policy on the Team Foundation Server to the individual projects was confusing. At times, I literally sat in amazement as I watched my own colleagues new to Code Analysis Policy struggle to perform the (what should have been an easy) task of finding a menu item.
Once the settings had been migrated, users were confused as to why the settings in the individual projects didn't match exactly what was stored in the project. For example, rules turned off in the policy, were still turned on in the project.

Our team actually knew about the confusion that issue 2 would cause when Visual Studio 2005 shipped. Surprisingly as it sounds, this behavior was actually the lesser of two evils. With the time that was available in the ship cycle they knew that they had two distinct choices, either a) have the policy completely override the settings stored in the project, or b) merge the policy settings with the project settings. Because a) prevented the scenario of allowing users to turn on more rules than the policy specified (in effect being stricter than the policy), the later was chosen as the preferred behavior.

Issue 1 was somewhat of a surprise. Code Analysis Policy along with the rest of Code Analysis was a late edition to Visual Studio 2005, probably too late to get any real user feedback and perform any actionable usability studies. We didn't hear about the troubles users were having with this until after the product had already shipped.

Once Visual Studio 2008 planning began, improving both of these issues was one of our top priorities, so we set about a feature crew to fix it.

Code Analysis Policy Failure Details dialog

Clearly users were first of all struggling to actually perform the migration; they were told by the Policy Failure that their projects settings were out-of-date, but not actually how to go about updating them. Even if they somehow figured out that a menu item might do this, looking intuitively on the individual project's context menus didn't help - the menu item that performed the job, Migrate Code Analysis Policy Settings to Solution (what a mouthful!), was hidden under File -> Source Control and on the solution's context menu.

The first thing we did to solve this confusion was to add a new dialog (displayed when double-clicking on a Code Analysis policy failure) that provided extra information about the situation they were in, what projects were out-of-date and how to go about solving it.

We also chose to tell them at this time that their build date was out-of-date - something that we previously only told them after they had updated their project settings and then attempted to check-in again (breaking their workflow).

New Policy Menu Items

The way to solve the second issue was easy; provide the user a choice:

Some users preferred policy to win out and completely overwrite the local project settings, whereas, others wanted to be able to specify additional rules above and beyond what was specified in the policy (ie the current Visual Studio 2005 behavior). The new Analyze menu (which I'll talk about in a future post), now provides two menu items, Replace with Check-in Policy and Merge with Check-in Policy, for performing both of these actions, respectively.

Hopefully these changes will make using Code Analysis Policy a little more pleasant experience in Visual Studio 2008. The new dialog and menu items themselves made into Beta 2 (albeit with slightly different text and names), so install it today and tell what you think.

New for Visual Studio 2008 - Custom Dictionaries

David M. Kean — Mon, 20 Aug 2007 17:00:00 GMT

Once you turn on the new spelling rules that we've added to Visual Studio 2008, you will want to start to customize the words that it fires on; this is where the new custom dictionary support comes in. A custom dictionary in its basic form, similar to the concept in Microsoft Word, allows you to silence the spell checker over the words that are not in the standard dictionary, such as company and product names.

Adding a custom dictionary to a project

To add a custom dictionary to a C# and Visual Basic project is simple:

In Solution Explorer, right-click on the project and choose Add -> New Item...
Under Templates, select XML File, enter a name for the dictionary, such as CodeAnalysisDictionary.xml and click Add
In Solution Explorer, right-click on the XML file and choose Properties
In the Properties tool window, under Build Action choose CodeAnalysisDictionary
In Solution Explorer, double-click on the newly created dictionary to open it
In the XML editor, paste the following, replacing [productname] and [companyname] with your team's equivalents:

<?xml version="1.0" encoding="utf-8" ?>
<Dictionary>
    <Words>
        <Recognized>
            <Word>[productname]</Word>
            <Word>[companyname]</Word>
        </Recognized>
    </Words>
</Dictionary>

You are now ready to start entering your own custom words. Simply add a new <Word> element for each word in your project that does not exist in the dictionary. Each word is case-insensitive, so any casing of the word will be recognized. Code Analysis will automatically pick up the custom dictionary the next time it is run.

Sharing a custom dictionary between projects

Once you have worked through the above steps, the following will be added automatically to your MSBuild-based project (ie csproj or vbproj):

This means that similar to other Code Analysis properties and items, this information can be placed a common targets file to be shared by multiple projects.

If you do not want to have all projects share a common MSBuild targets file, you can instead do the following:

Place the custom dictionary file created above in a shared location, such as alongside the solution
In Solution Explorer, right-click on a project and choose Add Item...
Browse to and click the custom dictionary to select it
On the Add button, click the down arrow to drop a menu and choose Add As Link
In Solution Explorer, right-click on the custom dictionary and choose Properties
In the Properties tool window, under Build Action choose CodeAnalysisDictionary
Repeat steps 2 - 6 for each project you want to share the custom dictionary

Advanced usage of a custom dictionary

I have shown you above basic usage of the new dictionary support the Code Analysis team has added to Visual Studio 2008. Those that have previously used custom dictionaries with FxCop, will realize that there are more things that you can add to these files that will customize other naming-based rules. However, for now I will leave you with the above and talk about advanced usage of a custom dictionary in future posts.

New for Visual Studio 2008 - Spelling rules

David M. Kean — Sun, 12 Aug 2007 17:00:00 GMT

Surprisingly, one the biggest requests for Code Analysis in Visual Studio 2005 was to include the spelling rules that shipped with the FxCop standalone. We had Microsoft consultants tell us that they actually had trouble moving some customers from FxCop to Code Analysis because they were not included. Apparently teams care about spelling. :)

Well, we've listened and I'm glad to tell you that we are shipping the following rules in Visual Studio 2008:

IdentifiersShouldBeSpelledCorrectly
CompoundWordsShouldBeCasedCorrectly
ResourceStringsShouldBeSpelledCorrectly
ResourceStringCompoundWordsShouldBeCasedCorrectly

These new rules (along with the rest of the previously FxCop-only rules) now cause the analysis in Visual Studio 2008 to become a true superset of what is available in FxCop.

API Rules

By default, the IdentifiersShouldBeSpelledCorrectly and CompoundWordsShouldBeCasedCorrectly, which both fire on the naming of API members, use the installed language of Visual Studio to determine the locale to spell check the identifiers in. To customize this, simply add the <CodeAnalysisCulture> MSBuild property to your project with a culture representing the language of the API you are writing:

It is advisable to explicitly specify above when you have developers working on different languages versions of Visual Studio. Unfortunately, due to some complex licensing reasons, we were only able to ship the English lexicons so only the English-based (en-US, en-GB, en-CA and en-AU in particular) cultures actually affect the spell checker. All other cultures cause the rules to silently disable themselves.

Resource Rules

The <CodeAnalysisCulture> property is used to indicate the language of your API identifiers; it is not, however, used to determine the language of your ResX-based resources. Instead, for these we use the same mechanism that the runtime uses (or more correctly, what the ResourceManager uses) to locate resources; the AssemblyCultureAttribute and the NeutralResourcesLanguageAttribute attributes. The former is applied to satellitte assemblies and should never be placed on an assembly with code. Whereas, the later is applied to an assembly with code to indicate the neutral culture of the assembly. These attributes are simply applied at the assembly level and are usually placed in each language's associated AssemblyInfo.cs/AssemblyInfo.vb file. The same cultures as above are supported.

Without one of these attributes on your assembly, the resources contained within it will never be checked by ResourceStringsShouldBeSpelledCorrectly and ResourceStringCompoundWordsShouldBeCasedCorrectly. Luckily, If you forget to apply the attribute, Mark assemblies with NeutralResourceLanguageAttribute, a new performance rule we've added, will remind you.

As you start to running the spelling rules - you might find that you need to add to the list of words that it recognizes - in the next post I will talk about the new custom dictionary support that we've added to Visual Studio 2008.

What rules do Microsoft have turned on internally?

David M. Kean — Thu, 09 Aug 2007 17:00:00 GMT

I've recently received a few requests asking about the Code Analysis rules we run internally against Microsoft's own code. While it might come as a surprise, we do not actually run every single rule against our own binaries. There are many reasons for this:

Applicability. Not every rule is applicable to every project, for example, the Design rules might be turned off if you are writing a Windows Application
Noise rate. Some rules have a low signal-to-noise ratio. While we try remove as much noise as possible from a rule, some rules, due to limitations in our analysis engine, still remain to be too noisy to be run regularly over large code bases. For example, some of the performance rules lack real context to make a good judge of whether a particular issue will really affect the performance of an application.
Time. We have to ship eventually - attempting to fix every single violation, for every single binary is just not feasible nor advisable. Therefore we make calls to turn off some rules that may lack value and do not impact the security of the product.

Please note that the following rule sets are applicable only to the Developer Division (although Windows does actually follow the same bar), other divisions, such as MSN, Office, etc each have their own set of enabled rules that may or may not be match what is shown below.

There are two rule sets; the first, Public Rule Set, is for assemblies that design for public consumption. That is, assemblies that are designed to have user take a reference to them in their own projects (such as System.Core.dll). The second, Non-Public Rule Set, is for assemblies are not designed to be consumed by users (such as FxCopCmd.exe). Both sets are listed below:

Public Rule Set:

Design
CA1008	EnumsShouldHaveZeroValue
CA1009	DeclareEventHandlersCorrectly
CA1011	ConsiderPassingBaseTypesAsParameters
CA1012	AbstractTypesShouldNotHaveConstructors
CA1014	MarkAssembliesWithClsCompliant
CA1017	MarkAssembliesWithComVisible
CA1018	MarkAttributesWithAttributeUsage
CA1019	DefineAccessorsForAttributeArguments
CA1023	IndexersShouldNotBeMultidimensional
CA1025	ReplaceRepetitiveArgumentsWithParamsArray
CA1026	DefaultParametersShouldNotBeUsed
CA1027	MarkEnumsWithFlags
CA1028	EnumStorageShouldBeInt32
CA1030	UseEventsWhereAppropriate
CA1032	ImplementStandardExceptionConstructors
CA1034	NestedTypesShouldNotBeVisible
CA1036	OverrideMethodsOnComparableTypes
CA1038	EnumeratorsShouldBeStronglyTyped
CA1039	ListsAreStronglyTyped
CA1040	AvoidEmptyInterfaces
CA1041	ProvideObsoleteAttributeMessage
CA1043	UseIntegralOrStringArgumentForIndexers
CA1044	PropertiesShouldNotBeWriteOnly
CA1045	DoNotPassTypesByReference
CA1046	DoNotOverloadOperatorEqualsOnReferenceTypes
CA1050	DeclareTypesInNamespaces
CA1051	DoNotDeclareVisibleInstanceFields
CA1052	StaticHolderTypesShouldBeSealed
CA1053	StaticHolderTypesShouldNotHaveConstructors
CA1054	UriParametersShouldNotBeStrings
CA1055	UriReturnValuesShouldNotBeStrings
CA1056	UriPropertiesShouldNotBeStrings
CA1057	StringUriOverloadsCallSystemUriOverloads
CA1058	TypesShouldNotExtendCertainBaseTypes
CA1059	MembersShouldNotExposeCertainConcreteTypes

Globalization
CA1300	SpecifyMessageBoxOptions
CA1301	AvoidDuplicateAccelerators
CA1304	SpecifyCultureInfo
CA1305	SpecifyIFormatProvider
CA1306	SetLocaleForDataTypes
CA1307	SpecifyStringComparison
CA1309	UseOrdinalStringComparison
CA2101	SpecifyMarshalingForPInvokeStringArguments

Interoperability
CA1401	PInvokesShouldNotBeVisible
CA1402	AvoidOverloadsInComVisibleInterfaces
CA1403	AutoLayoutTypesShouldNotBeComVisible
CA1404	CallGetLastErrorImmediatelyAfterPInvoke
CA1405	ComVisibleTypeBaseTypesShouldBeComVisible
CA1406	AvoidInt64ArgumentsForVB6Clients
CA1408	DoNotUseAutoDualClassInterfaceType
CA1413	AvoidNonpublicFieldsInComVisibleValueTypes

Naming
CA1700	DoNotNameEnumValuesReserved
CA1701	ResourceStringCompoundWordsShouldBeCasedCorrectly
CA1702	CompoundWordsShouldBeCasedCorrectly
CA1703	ResourceStringsShouldBeSpelledCorrectly
CA1704	IdentifiersShouldBeSpelledCorrectly
CA1707	IdentifiersShouldNotContainUnderscores
CA1708	IdentifiersShouldDifferByMoreThanCase
CA1709	IdentifiersShouldBeCasedCorrectly
CA1710	IdentifiersShouldHaveCorrectSuffix
CA1711	IdentifiersShouldNotHaveIncorrectSuffix
CA1712	DoNotPrefixEnumValuesWithTypeName
CA1713	EventsShouldNotHaveBeforeOrAfterPrefix
CA1714	FlagsEnumsShouldHavePluralNames
CA1715	IdentifiersShouldHaveCorrectPrefix
CA1716	IdentifiersShouldNotMatchKeywords
CA1719	ParameterNamesShouldNotMatchMemberNames
CA1720	IdentifiersShouldNotContainTypeNames
CA1721	PropertyNamesShouldNotMatchGetMethods
CA1722	IdentifiersShouldNotHaveIncorrectPrefix
CA1724	TypeNamesShouldNotMatchNamespaces

Performance
CA1811	AvoidUncalledPrivateCode
CA1812	AvoidUninstantiatedInternalClasses
CA1813	AvoidUnsealedAttributes
CA1815	OverrideEqualsAndOperatorEqualsOnValueTypes
CA1816	DisposeMethodsShouldCallSuppressFinalize
CA1819	PropertiesShouldNotReturnArrays

Portability
CA1900	ValueTypeFieldsShouldBePortable
CA1901	PInvokeDeclarationsShouldBePortable

Reliability
CA2001	AvoidCallingProblematicMethods
CA2002	DoNotLockOnObjectsWithWeakIdentity
CA2004	RemoveCallsToGCKeepAlive
CA2006	UseSafeHandleToEncapsulateNativeResources

Security
CA2102	CatchNonClsCompliantExceptionsInGeneralHandlers
CA2103	ReviewImperativeSecurity
CA2104	DoNotDeclareReadOnlyMutableReferenceTypes
CA2105	ArrayFieldsShouldNotBeReadOnly
CA2106	SecureAsserts
CA2107	ReviewDenyAndPermitOnlyUsage
CA2108	ReviewDeclarativeSecurityOnValueTypes
CA2109	ReviewVisibleEventHandlers
CA2111	PointersShouldNotBeVisible
CA2112	SecuredTypesShouldNotExposeFields
CA2114	MethodSecurityShouldBeASupersetOfType
CA2115	CallGCKeepAliveWhenUsingNativeResources
CA2116	AptcaMethodsShouldOnlyCallAptcaMethods
CA2117	AptcaTypesShouldOnlyExtendAptcaBaseTypes
CA2118	ReviewSuppressUnmanagedCodeSecurityUsage
CA2119	SealMethodsThatSatisfyPrivateInterfaces
CA2120	SecureSerializationConstructors
CA2121	StaticConstructorsShouldBePrivate
CA2122	DoNotIndirectlyExposeMethodsWithLinkDemands
CA2123	OverrideLinkDemandsShouldBeIdenticalToBase
CA2124	WrapVulnerableFinallyClausesInOuterTry
CA2126	TypeLinkDemandsRequireInheritanceDemands
CA2127	SecurityTransparentAssembliesShouldNotContainSecurityCriticalCode
CA2128	SecurityTransparentCodeShouldNotAssert
CA2129	SecurityTransparentCodeShouldNotReferenceNonpublicSecurityCriticalCode

Usage
CA1806	DoNotIgnoreMethodResults
CA2207	InitializeValueTypeStaticFieldsInline
CA2208	InstantiateArgumentExceptionsCorrectly
CA2209	AssembliesShouldDeclareMinimumSecurity
CA2211	NonConstantFieldsShouldNotBeVisible
CA2213	DisposableFieldsShouldBeDisposed
CA2214	DoNotCallOverridableMethodsInConstructors
CA2216	DisposableTypesShouldDeclareFinalizer
CA2217	DoNotMarkEnumsWithFlags
CA2218	OverrideGetHashCodeOnOverridingEquals
CA2220	FinalizersShouldCallBaseClassFinalizer
CA2221	FinalizersShouldBeProtected
CA2224	OverrideEqualsOnOverloadingOperatorEquals
CA2225	OperatorOverloadsHaveNamedAlternates
CA2227	CollectionPropertiesShouldBeReadOnly
CA2228	DoNotShipUnreleasedResourceFormats
CA2229	ImplementSerializationConstructors
CA2230	UseParamsForVariableArguments
CA2233	OperationsShouldNotOverflow
CA2234	PassSystemUriObjectsInsteadOfStrings
CA2235	MarkAllNonSerializableFields
CA2236	CallBaseClassMethodsOnISerializableTypes
CA2237	MarkISerializableTypesWithSerializable
CA2240	ImplementISerializableCorrectly

Non-Public Rule Set:

Globalization
CA2101	SpecifyMarshalingForPInvokeStringArguments

Portability
CA1900	ValueTypeFieldsShouldBePortable
CA1901	PInvokeDeclarationsShouldBePortable

Reliability
CA2002	DoNotLockOnObjectsWithWeakIdentity

Security
CA2100	ReviewSqlQueriesForSecurityVulnerabilities
CA2102	CatchNonClsCompliantExceptionsInGeneralHandlers
CA2103	ReviewImperativeSecurity
CA2104	DoNotDeclareReadOnlyMutableReferenceTypes
CA2105	ArrayFieldsShouldNotBeReadOnly
CA2106	SecureAsserts
CA2107	ReviewDenyAndPermitOnlyUsage
CA2108	ReviewDeclarativeSecurityOnValueTypes
CA2109	ReviewVisibleEventHandlers
CA2111	PointersShouldNotBeVisible
CA2112	SecuredTypesShouldNotExposeFields
CA2114	MethodSecurityShouldBeASupersetOfType
CA2115	CallGCKeepAliveWhenUsingNativeResources
CA2116	AptcaMethodsShouldOnlyCallAptcaMethods
CA2117	AptcaTypesShouldOnlyExtendAptcaBaseTypes
CA2118	ReviewSuppressUnmanagedCodeSecurityUsage
CA2119	SealMethodsThatSatisfyPrivateInterfaces
CA2120	SecureSerializationConstructors
CA2121	StaticConstructorsShouldBePrivate
CA2122	DoNotIndirectlyExposeMethodsWithLinkDemands
CA2123	OverrideLinkDemandsShouldBeIdenticalToBase
CA2124	WrapVulnerableFinallyClausesInOuterTry
CA2126	TypeLinkDemandsRequireInheritanceDemands
CA2127	SecurityTransparentAssembliesShouldNotContainSecurityCriticalCode
CA2128	SecurityTransparentCodeShouldNotAssert
CA2129	SecurityTransparentCodeShouldNotReferenceNonpublicSecurityCriticalCode

Usage
CA2233	OperationsShouldNotOverflow

Now, while the above rules are set and mandated at the Division-level, individual teams can (and do) add additional rules. For example, most assemblies, whether public or not, at a minimum follow the Public Rule Set. The Code Analysis team itself actually turns on every single rule to run over the binaries that we release.

Also note that because they are set at the start of a product cycle and are not changed again until the start of the next cycle, rule sets do not include rules that are new to Visual Studio 2008 (with exception to security rules). This is prevent the situation of the introduction of a new rule causing existing code to be no longer be Code Analysis clean (ie moving the basket).

These rule sets will be revisited for Rosario and beyond.