Settings FxCop ruleset on project

Sep 5, 2013 at 6:36 AM
Currently SPSF integrates FxCop in i'ts custom MSBuild target, which work fine for checking rules during build. But with this setup it's not possible to run code analysis during development, especially since rules are defined one by one and not with a ruleset.

Wouldn't it be possible to
  1. Define rules in a ruleset file
  2. Set ruleset file in project properties
With this it would be possible to run FxCop on its own and still have build integration. Same goes for StyleCop
Sep 5, 2013 at 6:47 AM
The ruleset for both FxCop and StyleCop are located in the ApplicationConfiguration solution folder and can be customised to your likings.

SPSF uses the external installed FxCop, because in VS2010 the internal CodeAnalysis is only available with the Ultimate license.

SPSF configures the project to run FxCop, StyleCop, SPCop/SPCAF and SPDisposeCheck on the RELEASE build configuration. You can change that in the SPSF.targets file (make sure to reload the solution after a change here, as VS caches this file)

For running CodeAnalysis on the fly during development (without compilation), you require third party tools like Resharper or Justcode.

Using the rulesets in the project properties would make no sense to me, as usually a SharePoint solution has not only one but multiple WSPs. Therefore you would require to keep the enabled, disabled rules in sync among all projects.

With the external file like it is implemented in SPSF right now, you are also able to use the exact same ruleset when running a TeamBuild on TFS, or even replace the ruleset with on stored centrally in SourceControl in order to assure that developers don't circumvent rules by just deactivating them.
Sep 5, 2013 at 6:58 AM
I don't see FxCOp and StyleCop rulesets in the ApplicationConfiguration. I've a Settings.FxCop and a Settings.StyleCop file, but not rulesets.

If you have a VS Version which supports Code Analysis it would make sense to use the internal Code Analysis, especially since VS 2012 which contains additional DataFlow rules compared to the standalone FxCop. Runing CodeAnalysis during development makes perfectly sense if you have a VS Version which includes Code Analysis. In this case you won't need any 3rd Party tools.

For keeping the rules in sync you would have the ruleset file (which additionally also can be inherited to help for example define company wide rule settings over multiple solutions). Build servers can also use the ruleset defined on the project, this gives you also additional flexibility to define different rules for different assemblies (for example unit test assemblies, etc).
Sep 5, 2013 at 7:06 AM
Settings.FxCop and Settings.StyleCop are the rulesets which can be edited with the respective ruleset editors of the tools.

If you have a VS Version which supports this, then you can deactivate the external analysers upon creation of the VS solution, or disable them with the SPSF configuration recipe.

If the current implementation in SPSF does not fit your needs, then you should consider disabling the respective checks. SPSF is just a guidance package to ease development. It is not a one-fit all approach. As practices and requirements are different in each development team adjustments might be necessary. The practices and conventions are based on our personal experiences and preferences.