Code Analysis Team Blog : Team System

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

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.

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.

$(CodeAnalysisTreatWarningsAsErrors) MSBuild property

David M. Kean — Wed, 08 Aug 2007 10:00:00 GMT

For Visual Studio 2008, we have added a new MSBuild property that allows you to easily treat all Code Analysis warnings as build errors. This can be useful for example, if you want to force that any firing of a Code Analysis rule to break the build during a nightly Team Build without needing to individually set this for every rule.

To use, simply add the <CodeAnalysisTreatWarningsAsErrors> property to your project file (or a common targets file) and set it to true:

Now, in the next run of Code Analysis, all rules will be displayed as errors:

Come chat with the Code Analysis team (and Team System) team - tomorrow

David M. Kean — Wed, 01 Aug 2007 08:08:00 GMT

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

We will be holding two sessions:

Join the chat on Wednesday, August 1st , 2007 from 10:00am - 11:00am Pacific Time. Add to Calendar | Additional Time Zones

-and-

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

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.

Come chat with the Team System product team tomorrow

David M. Kean — Tue, 03 Jul 2007 08:50:00 GMT

Join members of the Visual Studio Team System product group to discuss features available in Visual Studio Team Foundation Server, Team Editions for Architects, Developers, Database Pros, and Testers. In addition, discuss what's new in the upcoming Orcas CTP.

We will be holding two sessions:

Join the chat on Tuesday, July 3rd , 2007 from 10:00am - 11:00am Pacific Time. Add to Calendar | Additional Time Zones

-and-

Join the chat on Tuesday, July 3rd, 2007 from 4:00pm - 5:00pm Pacific Time. Add to Calendar | Additional Time Zones