FxCop

CA1502:AvoidExcessiveComplexity and Lambdas

EltonStoneman — Mon, 21 Sep 2009 20:47:01 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

In code with lots of lambda expressions, you may trigger a false positive for the Code Analysis rule CA1502 "AvoidExcessiveComplexity". The rule calculates cyclomatic complexity using the logic in Microsoft.FxCop.Sdk.MethodMetrics, which enumerates the instruction set and increments complexity count when it finds one of a given set of opcodes.

The rule was triggered by code which uses the Fluent DAL approach to populate a composite entity:

public static Entity GetEntity(int entityId)

{

//populate basic details:

Entity entity = Fluently.Load<Entity>().With<EntityMap>()

.From<GetEntity>(i => i.Id = entityId,

x => x.Execute());

//load child entities:

if (entity.IsKnown)

{

entity.Address = Fluently.Load<Address>().With<AddressMap>()

.From<GetEntityAddresses>(i => i.Id = entityId,

x => x.Execute());

entity.Contact = Fluently.Load<Contact>().With<ContactMap>()

.From<GetEntityContacts>(i => i.Id = entityId,

x => x.Execute());

}

else

{

//more of the same...

The method in question had a single if/else branch, no other conditional logic, but 7 fluent calls totalling 12 lambdas. I calculate the cyclomatic complexity to be 2, and NDepend agrees. FxCop tells me the complexity is 26.

I stripped this down to a much simpler sample and found the same issue:

public void CCCheck2()

{

Fluently.Load().With().From(i => i.ToString(), x => x.ToString());

}

- this gives a CC of 13, although it has no conditional logic at all.

The answer's in the IL – the lambdas are emitted as private static classes and executed using an instance which is lazy-loaded:

IL_000b: ldsfld class [System.Core]System.Func`2<int32,string> FxCopCC.LambdaSample::'CS$<>9__CachedAnonymousMethodDelegate6'

IL_0010: brtrue.s IL_0025

IL_0012: ldnull

IL_0013: ldftn string FxCopCC.LambdaSample::'<CCCheck>b__0'(int32)

IL_0019: newobj instance void class [System.Core]System.Func`2<int32,string>::.ctor(object,

native int)

IL_001e: stsfld class [System.Core]System.Func`2<int32,string> FxCopCC.LambdaSample::'CS$<>9__CachedAnonymousMethodDelegate6'

IL_0023: br.s IL_0025

br and brtrue are transfer of control statements, so every lambda expression actually causes a branch – where the IL checks to see if there's a cached instance of the delegate, or whether it needs to instantiate one – and a return. The complexity rating is correct for the IL, as 1 + 2x(number of lambdas).

But cyclomatic complexity is a measure of readability, so the additional branches in the IL should be irrelevant. The short term solution is to suppress the message on methods with heavy lambda usage. A longer term option is an alternative rule which uses a different calculation.

A side point is that the IL isn't aggressively optimised by the compiler – lambdas with identical code are generated as separate private classes, each with their own lazy-loading check, so to avoid that overhead lambdas which are reused can be centralised:

private Func<int, string> GetInitialise()

{

return new Func<int,string>(i => i.ToString());

}

Configurable FxCop Rules

EltonStoneman — Tue, 18 Nov 2008 01:41:41 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

FxCop allows you to define rules as having configurable settings, and through the native UI you can override the settings and save them for each FxCop project. This is useful if you want to have a generic set of rules that can be used to enforce differing sets of standards, without having to modify the rule assemblies.

It's not well documented, but you need to implement IConfigurableRule and provide default setting values. There's a straightforward sample on Dennis Forbes' blog, but you can move the IConfigurableRule implementation to a base class and just have the specific setting code in the child class:

Bear in mind that FxCop will instantiate an instance of the rule prior to firing it during analysis, and will cache that instance for all analysis runs, so your configuration code should account for this. Key things to note:

Settings are held in two IDictionary objects, representing the default settings and the current settings. In theory any dictionary type will do, but I had problems with using generic dictionaries, so resorted to using Hashtable;
Add values to the default setting collection in a static constructor, then use ConfigurationHelper.CopyFromDefault() to copy default settings to the current setting collection. This has to be in a static constructor, lazy-loading the DefaultSettings property won't work;
Use ConfigurationHelper.LoadSettings() in your implementation of LoadSettings, to update the current dictionary with saved values from the FxCop project file;
Use ConfigurationHelper.SaveSettings() in your SaveSettings implementation to copy the current setting values back to the FxCop project file. FxCop will only call this if the current settings differ from the defaults;
There's no event model to notify when current settings have been changed, so if you're caching downstream based on a setting value, you'll need to check the cache is valid before each call.

The need to set up defaults in a static constructor complicates the implementation of the base class. One option is to store a static collection of Hashtables in the base class, keyed by the child class type name (this is the implementation I used in BizTalkCop, full code samples there).

Introducing: BizTalkCop

EltonStoneman — Fri, 14 Nov 2008 16:36:06 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

To make good on a rash comment around the lack of standards-enforcement for BizTalk, I've put together a set of FxCop rules which allow you to run static analysis over BizTalk solutions. It covers all aspects by running rules against compiled artifact assemblies and configured BizTalk applications. It's on CodePlex here: BizTalkCop.

The first release(1.0) contains a full ruleset for validating BizTalk application artifact names, based on Scott Colestock's naming conventions. By default the rules are more strict in places, but they're configurable so you can modify them to suit your own standards.

Usage

Currently BizTalk projects don't integrate fully with static analysis in VS 2005, so you'll need the separate FxCop UI – latest version is FxCop 1.36. Once you've installed FxCop, run the BizTalkCop installer and it will add BizTalkCop.Rules.dll and BizTalkCop.Rules.chm to the FxCop rules folder (default: Program Files\Microsoft FxCop 1.36\Rules). Open FxCop and there are three steps to configure your BizTalk project:

1. Add Targets

Add the compiled BizTalk assemblies you want to check to the FxCop project. For compiled artifacts, BizTalkCop covers orchestrations, maps, schemas and pipelines so you can add any assemblies that contain these:

2. Select Rules

If you've used the default installation, then the BizTalkCop rule set should be listed in the Rules tab (if not you'll need to navigate to add it). Check BizTalkCop and uncheck all the others:

3. Set up Application Configuration

In order to validate the configured BizTalk Application, you'll need to specify the location of your management database, and the name of the Applications to check. Open the ApplicationConfig rule properties (this is a dummy rule which is only there to capture BizTalk Server config), and modify the Settings to specify your server, and the Applications to run over (semi-colon separated if more than one) – you only need to do this once, and all Application rules will use these settings:

When you run FxCop it'll list all the rule failures, some of which may have multiple issues (e.g. ReceiveLocationNamesShouldIndicateTransport will flag an issue for every configured location that doesn't have its transport type as a suffix). There should be no locks on targets, so you can change the artifacts and recompile, or edit application config with FxCop open, and then re-run it.

Most rules are configurable, so you can modify the prefixes and suffixes to suit your standards, or ignore any rules you don't care for. Save the project as a .FxCop file and you can integrate this into your build process using the MSBuild Community Tasks.

Development

There's potential for rules to cover a lot more than the "Naming" category. Certain of the recommendations in the BizTalk Performance Optimization Guide are candidates for a "Performance" category, and there are a few gotchas that could be avoided with warnings from a "Design" category. I'm not planning to add these for a while, but if you want to get involved let me know and I'll add you as a contributor.

FxCop runs over compiled assemblies, so introducing it to BizTalk meant for a few workarounds. If you want to extend BizTalkCop by adding new rules, there are a set of base classes which will help:

RuleBase – general base class for rules using normal introspection over classes; contains methods for determining if targets are maps, schemas etc;
ConfiguredRuleBase – base class for rules which have default setting values which can be overridden in the project file;
ApplicationRuleBase – base class for rules analysing BizTalk Applications; wraps the Explorer OM (so not good for 64-bit) to get the current config;
OrchestrationRuleBase – base class for analysing Orchestrations; typically the compiled code is too dense for analysis, so the base class exposes methods for accessing the shape and OM configuration. This is stored as XML in the compiled class, and the base class provides XPath helpers to access it.

The code for running the rule is quite straightforward, although tracking down the XML elements to check can be fiddly for orchestration rules (if you can find any schemas for the shape or OM XML, let me know and I'll modify it all to use entity classes). The source code contains a sample BizTalk project which fails all known rules, so you can add to this to check your own rules run as expected.

Quite possibly the CSD have something like this in place for the VS 2008 integration coming in BizTalk Server 2009. If not, it should be a trivial job to migrate these rules to run under VS, and in any case the ability to separate them out for running in the build should be useful.

I've run the rules over a few solutions and they've been accurate, but if you come across any issues, log them on CodePlex and I'll have a look.