Welcome to MSDN Blogs Sign in | Join | Help

What rules do Microsoft have turned on internally?

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.

Published Thursday, August 09, 2007 7:00 AM by David M. Kean

Comments

Friday, August 10, 2007 1:56 AM by From the software development trenches

# Izindaba #4

Time for another weekly roundup of news that focuses on .NET and general development related content

Friday, August 10, 2007 10:18 AM by Hugo Ribeiro

# Code Analysis @ Microsoft

Well, it turns out that Microsoft (Developer Division) itself isn't using all the code analysis (FxCop)

Tuesday, August 14, 2007 9:03 AM by Team System News

# VSTS Links - 08/14/2007

The Visual Studio Code Analysis Team Blog on What rules do Microsoft have turned on internally? Bret...

Thursday, August 16, 2007 11:40 AM by Jeff Boyd

# Here are some other things to check

Here are some static code analysis features I have found useful.

I'm interviewing with Microsoft on August 20, 2007, in Redmond, if anyone would like to discuss code analysis, etc.

Thanks

JeffBoyd@yahoo.ca

      AssertValid checking to add. Code is generated to create AssertValid functions and test each pointer data member.

      Boolean members to add to class 'Bool'. This lets meaningful names be used as parameters, instead of 'true' and 'false'.

      Class members not in a section.

      Class members without a name.

      Code to move to a section.

      Files to rename to match the class name.

      Files with the same name, in different directories.

      Function-body code-blocks to add.

      Function-parameters with unknown words.

      Functions with an undocumented return value.

      Functions with multiple return statements.

      Functions without definitions.

      Globals to move to a class.

      Large '.obj' files.

      Local variables with unknown words.

      Multiple variables declared in the same statement.

      Names that appear in both the 'known' and 'misspelled' word lists.

      New and misspelled words found in comments and identifiers.

      Sections that are nested.

      Sections to merge.

      Sections to move, to be alphabetically sorted.

      System-class function-calls to update to library-class function-calls.

      Tokens to update to macros.

      Undocumented classes.

      Undocumented data.

      Undocumented functions.

      And more.

  The Reports check:

      Class hierarchy organization.

      Constructor error checking.

      Constructor initializer lists.

      Destructor error checking.

      That related code is in the same section.

  The Reports help:

      Create a classes organizational tree, which is displayed by the browser.

      Sort lint messages and remove duplicate messages, to make linting faster.

      Rename class-member data names to start with 'm_'.

      Rename class-member names to contain known words.

      Rename class-member names to end with their type.

      Rename classes.

      Rename function local variables.

      Rename function return-values to start with 'result_'.

      Rename function-parameters.

      Rename functions.

  The Reports:

       AssertValid checking.messages

       AssertValid.messages

       autoexp

       char.messages

       Check_constructor_error_checking.messages

       Check_constructor_initializer_lists.messages

       Check_that_related_code_is_in_the_same_section.messages

       Class Bool.messages

       Class hierarchy.messages

       Class members not in a section.messages

       Class members without a name.messages

       Class-member names used in more than one section.messages

       Classes organizational tree.messages

       Code to move to a section.messages

       File to rename to match the class name.messages

       Files with the same name.messages

       Function-body code-blocks to add.messages

       Function-parameters with unknown words.messages

       Functions with an undocumented return value.messages

       Functions with multiple return statements.messages

       Functions without definitions.messages

       Globals.messages

       Large obj files.messages

       Lint

       Local variables with unknown words.messages

       Move_code.messages

       Multiple variables declared in the same statement.messages

       Names that appear in both the 'known' and 'misspelled' word lists

       new and misspelled words found in  comments.messages

       new and misspelled words found in library module # comments.messages

       new and misspelled words.messages

       Rename class-member data names to start with 'm_' - These names are used more than once.messages

       Rename class-member data names to start with 'm_'.messages.messages

       Rename class-member names - These names are used more than once.messages

       Rename class-member names to end with their type - These names are used more than once.messages

       Rename class-member names to end with their type.messages

       Rename class-member names.messages

       Rename function local variables.unsorted.messages

       Rename function return-value to start with 'result_'.messages

       Rename function-parameters.sorted.messages

       Rename Function-parameters.unsorted.messages

       Sections that are nested.messages

       Sections to merge.messages

       Sections to move, to be alphabetically sorted.messages

       spell_checking_Enabled

       System #include statements that do not use angle brackets.messages

       System objects to update to library objects.messages

       system-class function-calls.messages

       tokens_to_update_to_macros.messages

       Undocumented classes.messages

       Undocumented data.messages

       Undocumented functions.messages

       usertype

Thursday, August 16, 2007 11:48 AM by Jeff Boyd

# Email address correction

My correct email address is Jeffers_Boyd@yahoo.ca

Sunday, August 19, 2007 9:56 AM by Peter Ritchie

# re: What rules do Microsoft have turned on internally?

Hi David.  Has CA1040 been removed from the public set for VS2008 or LINQ?  There are some empty interfaces in LINQ.

Monday, August 20, 2007 1:28 PM by David M. Kean

# re: What rules do Microsoft have turned on internally?

Peter: No CA1040 (AvoidEmptyInterfaces) has not been removed from the public set, however, it appears that we have a bug in the rule that prevents it from firing on some of the interfaces in System.Core.dll. We have logic that does not fire (correctly) if you combine two or more interfaces, however, it should (but currently doesn't) fire when combining two interfaces and one of them is already in your hierarchy. I've filed a bug on this, however, it will be likely fixed post Visual Studio 2008.

Friday, August 24, 2007 11:52 AM by Peter Ritchie

# re: What rules do Microsoft have turned on internally?

Hmm, interesting.  I guess that means the empty interfaces in LINQ will remain...

Friday, September 21, 2007 10:14 AM by Mike

# re: What rules do Microsoft have turned on internally?

CA2217 DoNotMarkEnumsWithFlags

CA1027 MarkEnumsWithFlags

These seem to conflict. How can you run with both?

Friday, September 21, 2007 10:56 AM by David M. Kean

# re: What rules do Microsoft have turned on internally?

Mike,

They seem in conflict but they are not.  One checks for enums that are marked with [Flags] but shouldn't be and the other checks for enums that aren't marked with [Flags] but should be. Confusing - hopefully in the future we can merge them to reduce the confusion.

Regards

David

Wednesday, October 10, 2007 6:08 AM by Messaoud

# re: What rules do Microsoft have turned on internally?

Hi,

I am using TFS2008 and VS2008 (beta2).

The point is that I cannot find the CA 1062  rule (check paramters against null)... Where is it ?

Where is the CA 1818 (stringbuilder usage) ?

Thanx in advance,

Messaoud

Wednesday, October 10, 2007 1:39 PM by David M. Kean

# re: What rules do Microsoft have turned on internally?

Messaoud: Unfortunately, these rules were based on our old data flow engine and were removed when it was removed from the product. We will be recovering them in a future version of Visual Studio.

Friday, October 12, 2007 3:10 AM by Jan Schreuder on .Net

# What FxCop rules do Microsoft have turned on internally?

Ever wondered if Microsoft use FxCop themselves, and which rules they have turned on? Well, the Visual

Sunday, October 14, 2007 10:55 AM by Hosam Kamel

# Microsoft internal Code Analysis rules

David M. Kean , has posted a list of Code Analysis rules which runs internally against Microsoft's own

Sunday, October 14, 2007 2:23 PM by The Other Steve

# re: What rules do Microsoft have turned on internally?

One of the things I have found most irritating about FxCop are the default rules which are not meaningful to most programs, such as CA2210 - Assemblies should have strong names

The vast majority of developers out here in the real world don't understand these things.  They see it come up as a warning, and think it's important to fix.

It would be nice if Microsoft configured fxcop by default with a intelligent set of rules.  Basically like this list.  Then if groups wanted to enable things above and beyond that, they could.  But it would save a lot of headaches and arguments.

Thanks for this list

Monday, October 15, 2007 12:30 AM by vik20000in

# re: What rules do Microsoft have turned on internally?

Thanks for posting This stuff. Surely will be helpful

Tuesday, October 16, 2007 7:24 AM by guidmaster´s .NET blog

# links for 2007-10-16

The Visual Studio Code Analysis Team Blog : What rules do Microsoft have turned on internally? (tags

Saturday, October 27, 2007 6:04 AM by JIRA: Quartz.NET

# [QRTZNET-59] Go trough code with Microsoft FxCop public rule set

Friday, November 23, 2007 5:21 AM by From the software development trenches

# FxCop

In previous posts about Code Metrics and Code Reviews , I explored some metrics and techniques that I

Sunday, November 23, 2008 10:36 PM by Chad's View of the World

# Rules to Enable When Using Code Analysis

Rules to Enable When Using Code Analysis

Thursday, February 05, 2009 12:32 PM by Termékinformációk fejlesztőknek

# Visual Studio Team System 2008 Development Edition with MSDN Premium Subscription

[ Nacsa Sándor , 2009. január 19. – február 5.] Ez a Team System változat fejlett eszközrendszert kínál

Thursday, March 12, 2009 10:41 PM by Andreas Zenker

# What is code quality?

Recently I had the chance to examine, in detail, each of the code analysis rules built into Visual Studio

New Comments to this post are disabled
 
Page view tracker