Code Analysis Team Blog : FxCop

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

New Code Analysis Features in Visual Studio 2010 September '08 CTP

cristend — Thu, 30 Oct 2008 20:05:00 GMT

At this year's PDC, Microsoft released 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 are interested in code analysis, you need to get this CTP and here is why.

The code analysis team is excited to share with you new code analysis features and rules in this CTP, including:

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
Enhanced policy support - enforce your rule set with the code analysis check-in policy
8 New Data Flow rules - find hard-to-detect flaws with these advanced dataflow rules for managed code; including certain SQL injection vulnerabilities

Included with the CTP is a walkthrough guide. Inside the walkthrough is a section dedicated to these exciting code analysis scenarios. Over the next couple of weeks we will continue to blog about rule sets, policy support, and data flow rules so be sure to come back after you get the CTP.

Now go get the CTP and starting sending us your feedback! http://go.microsoft.com/fwlink/?LinkId=129231

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

David M. Kean — Mon, 25 Aug 2008 17:00:00 GMT

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

FxCop 1.36 Released!

brettwo — Tue, 19 Aug 2008 23:11:00 GMT

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

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

FAQ: How do I prevent FxCop 1.36 from firing warnings against generated code?

David M. Kean — Thu, 28 Feb 2008 21:39:29 GMT

I've upgraded from FxCop 1.35 to 1.36 and now FxCop has started to fire warnings against typed DataSets and other generated code. How do I turn this off?

The reason this is occurring is because we changed the way that FxCop analyzed generated code. Whereas previously in 1.35, FxCop would only ignore particular generated code (such as DataSets), FxCop 1.36 will now either ignore no generated code, or all generated code. The former is the default.

To change this behavior and have FxCop skip over generated code:

Using an FxCop project:

Open your FxCop project in FxCop
Choose Project -> Options -> Spelling & Analysis
Check Suppress analysis results against generated code
Click OK

Via the command-line:

Pass the /ignoregeneratedcode switch, for example:

FxCopCmd.exe /file:MyAssembly.dll /out:AnalysisResults.xml /ignoregeneratedcode

For more information on FxCop's behavior over generated code, see Correct usage of the CompilerGeneratedAttribute and the GeneratedCodeAttribute.

What happened to the download and documentation of FxCop 1.35?

David M. Kean — Wed, 27 Feb 2008 02:45:00 GMT

Update: You can now download FxCop 1.35 directly from MSDN Code Gallery.

As you many you have well noticed, GotDotNet was officially retired last month now that the last of its functionality was superceded by MSDN Code Gallery. Unfortunately, at the same time, the FxCop team page, the download for FxCop 1.35 and the rule documentation was also removed.

We were told last year about the deprecation of GotDotNet and we had hoped that by now we would have had a new team site on MSDN, however, a variety of factors, some within our control and some beyond our control, prevented that from happening in time.

In the meantime, while we sort out new home for our beloved FxCop, here are a couple of workarounds:

To download FxCop

Upgrade to FxCop 1.36 Beta. This is one of our most stable beta's to-date; which is not surprising considering that some of the same bits also shipped in Visual Studio 2008. Go ahead, download FxCop 1.36 today - you won't be disappointed.
Download the Windows SDK. The Windows SDK includes the FxCop 1.35 setup. You might already have it installed if you have Visual Studio 2008, otherwise, download it. Either way, once installed, FxCop 1.35 setup can be found via Start -> All Programs -> Microsoft Windows SDK [Version] -> Tools -> Install Microsoft FxCop.

To view the documentation

MSDN Library. Both the FxCop documentation and rule documentation are available on the MSDN Library.
Installed Help. FxCop 1.35 comes with a CHM (pronounced 'chum') containing FxCop and rule documentation. Albeit a little out-of-date when compared to the online version, access it via Start -> All Programs -> Microsoft FxCop 1.35 -> FxCop Documentation or via Help -> Using Microsoft FxCop inside FxCop.

Tutorial on writing your own Code Analysis rule

David M. Kean — Fri, 18 Jan 2008 18:00:00 GMT

Jason Kresowaty has posted a great tutorial on writing Code Analysis/FxCop rules. He also spends time on explaining parts of the Introspection API, including the different nodes and their relationship to each other.

It's a great read, even if you've written some Code Analysis rules before. Definitely recommended.

FAQ: Which Code Analysis rules shipped in which version?

David M. Kean — Mon, 07 Jan 2008 21:04:00 GMT

In response to a lot of recent requests, we've put together a complete list of rules that shipped in the different versions of Visual Studio Code Analysis and FxCop. Attached is an Excel worksheet providing this information for Visual Studio 2005, Visual Studio 2008, FxCop 1.35 and FxCop 1.36 Beta.

One of things you'll notice as you read through the list is that we removed some rules from the later versions. There are a few reasons for this:

Noise and applicability. We use feedback from customers, SQM data (to see which rules users turn off), and input from internal teams (Windows, Office, CLR, etc) to determine the rules that are noisy without adding any perceivable value. There are also rules that are either no longer applicable or can no longer fire. for example, a rule could have been firing on a limitation of the CLR which has since been fixed in later versions.
Merged rules. Sometimes it makes sense to merge rules that fire on similar things, for example, the analysis in SecureGetObjectDataOverrides was already covered by OverrideLinkDemandsShouldBeIdenticalToBase, so these two rules were merged. Similarly, LongAcronymsShouldBePascalCased, ShortAcronymsShouldBeUppercase and IdentifiersShouldBeCasedCorrectly all fired on the casing of identifiers, and hence were merged in the later.
Analysis engine removed. In Visual Studio 2008 and FxCop 1.36 we removed one of our analysis engines. This engine was removed for a variety of reasons; it increased analysis time (although the engine encompassed less than 5% our analysis, it took up 50% of our time-to-analyze), indeterministic results (results appearing and disappearing between runs), and bugs found within the engine (and hence the rules that depended on it) required huge architectural changes. We instead decided to invest the resources that we would have spent on fixing the old engine, on a new data flow analysis engine based on Phoenix, which we will ship in a future version of Visual Studio.

There are also more differences between Visual Studio Code Analysis and FxCop than just the rules - in a future blog post I will cover these in detail.

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.

FxCop 1.36 Beta Released!

David M. Kean — Wed, 10 Oct 2007 23:09:10 GMT

I'm pleased to announce that we've released a beta of the next version of FxCop. This release has a number of changes since FxCop 1.35, 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 in the command-line via /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 I 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.

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.

FxCop Designers Honored with the Engineering Excellence Chairman's Award

David M. Kean — Thu, 05 Jul 2007 18:00:00 GMT

Mike Fanning, Krzysztof Cwalina, and Brad Abrams were awarded with the Engineering Excellence Chairman's Award for the design of FxCop, which is given for contributions that Bill Gates considers extremely important:

The Engineering Excellence Chairman's Award is Microsoft's highest award for engineering group employees worldwide. This award recognizes and rewards individuals that have pioneered noteworthy innovations in their drive for engineering excellence. Receiving the Engineering Excellence Chairman's Award is a level of recognition that only a few of our finest employees achieve.

This is an awesome achievement and something that they all deserve. Congratulations!

Krzysztof has more information on his blog: http://blogs.msdn.com/kcwalina/archive/2007/07/03/EEAward.aspx

What kind of custom rules do you want to write?

David M. Kean — Wed, 04 Jul 2007 18:00:00 GMT

Our excellent program manager, Joe Rohde, is trying to gather information on the kinds of custom rules customers want to write.

I am a program manager for our Code Analysis system. I want to know what kind of custom rules you would like to write. Ignore what you may or may not know about what's in FxCop already. If you could track anything - tell me what you want!

I don't care if it's things you know we can't do - except maybe 'find my bugs'. Tell your friends, tell anyone who has ever said: I wish this thing could...

The reason I want everything is both to help plan the rules we should just plain provide; and how to best provide an actual supported extensibility feature.

Please send what you would like to see to: JRohde@Microsoft.com

Thanks!

Joe

Provide Joe with feedback and help us plan our future extensibility.