Use code analysis with Visual Studio DNX project (.xproj)

Question

Within the properties of an "ordinary" Visual Studio project (.csproj) it's possible to say Enable Code Analysis on Build (formerly known as FxCop).

Since I've started playing around with new DNX projects (.xproj) I'm searching for something similar. I know there may be no build output, so the old approach may not really fit into this, but I'm quite sure the Code Analysis / FxCop rules still apply. Furthermore there should be some way to register a custom rule set (.ruleset) file within the new "actual" project file (project.json).

Maybe I'm overlooking something more modern based on Roslyn or the like?

Answer 1

There is an issue for this on the ASP.NET Tooling GitHub site here. It is currently unsupported but will hopefully get implemented soon. Code analysis will work again when the switch from xproj back to csproj is made.

Update

StyleCop.Analyzers is now supported with xproj.

Answer 2

Finally found a workaround, which should do it until they'll (hopefully) fix it with the next release of .NET Core and Visual Studio. The trick is to execute the "good old" FxCop for the classic .NET Framework build, which is necessary to run an old fashioned code analysis.

The project.json for libraries should contain something like that:

{
  "frameworks": {
    "net46": {
      "buildOptions": {
        "define": [ "CODE_ANALYSIS" ]
      }
    },
    "netstandard1.3": {
      "dependencies": {
        "NETStandard.Library": "1.6.0"
      }
    }
  },

  "scripts": {
    "postcompile": "../../CodeAnalysis.cmd %compile:TargetFramework% %compile:Configuration% %compile:OutputFile% %compile:CompilerExitCode%"
  }
 }

The project.json for "apps" should include the actual runtime:

{
  "scripts": {
    "postcompile": "../../CodeAnalysis.cmd %compile:TargetFramework% %compile:Configuration% %compile:OutputFile% %compile:CompilerExitCode% %compile:RuntimeOutputDir%"
  }
 }

Thus, using the postcompile event makes it possible to run some kind of batch script to execute the classic FxCop (Visual Studio required!). I'm currently using a setup with three files:

• CodeAnalysis.cmd
• CodeAnalysis.ruleset
• CodeAnalysis.xml (dictionary)

The batch file "supports" the current .NET Framework 4.6 versions and looks like this:

@echo off

if not [%4]==[0] (
  goto :eof
)

if not [%2]==[Release] (
  goto :eof
)

if [%1]==[net46] (
  set VERSION=v4.6
) else if [%1]==[net461] (
  set VERSION=v4.6.1
) else if [%1]==[net462] (
  set VERSION=v4.6.2
) else (
  goto :eof
)

if not [%5]==[] (
  set FILE=%5\%~nx3
) else (
  set FILE=%3
)

set PLATFORM=%ProgramFiles(x86)%\Reference Assemblies\Microsoft\Framework\.NETFramework\%VERSION%
set DIRECTORY=%ProgramFiles(x86)%\Reference Assemblies\Microsoft\Framework\.NETFramework\%VERSION%\Facades

set FXCOP=%VS140COMNTOOLS:Common7\Tools=Team Tools\Static Analysis Tools\FxCop%FxCopCmd.exe
set RULES=%VS140COMNTOOLS:Common7\Tools=Team Tools\Static Analysis Tools\FxCop%Rules

"%FXCOP%" /platform:"%PLATFORM%" /directory:"%DIRECTORY%" /rule:"-%RULES%" /ruleset:"=%~dp0CodeAnalysis.ruleset" /dictionary:"%~dp0CodeAnalysis.xml" /file:"%FILE%" /ignoregeneratedcode /console /culture:de-DE

It's not that handy like the ordinary built-in stuff, but the errors / warnings of FxCop appear within the Error List when using Visual Studio (sometimes a second build is necessary). They don't lead to a failed build though (maybe there's another trick...).

CodeAnalysis.ruleset example:

<?xml version="1.0" encoding="utf-8"?>
<RuleSet Name="All Rules, except a few ones" ToolsVersion="14.0">
    <IncludeAll Action="Error" />
    <Rules AnalyzerId="Microsoft.Analyzers.ManagedCodeAnalysis" RuleNamespace="Microsoft.Rules.Managed">
        <!-- CLS compliant -->
        <Rule Id="CA1014" Action="None" />
        <!-- COM visibility -->
        <Rule Id="CA1017" Action="None" />
    </Rules>
</RuleSet>