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