0

I encounter a really weird behaviour with fxcopcmd.exe. If I launch the fxcopcmd.exe specifying only one assembly (Assembly X), there is no violations. But if I specify all the assemblies of the solution, it throws a lot of violation in (Assembly X). Is there something that I missed? Note that when using code analysis in visual studio, there is no violations even if I Run the Code Analysis for all the assemblies.

More details:

1- We use a solution in Visual Studio 2013 with six huge C# projects.

2- We use fxcopcmd.exe that comes from the installation of VisualStudio 2013 (Version 12.0.21005.1).

3- Example of command line command that do not detect any violation:

tools\FxCopCmd\FxCopCmd.exe /file:build\bin\Assembly1.dll /out:results.txt /ruleset:=Tools\FxCopRuleSet\CompagnyRules.ruleset /ignoregeneratedcode

4- Example of command line command that detects violations:

tools\FxCopCmd\FxCopCmd.exe /file:build\bin\Assembly1.dll /file:build\bin\Assembly2.dll  /file:build\bin\Assembly3.dll /file:build\bin\Assembly4.dll /out:results.txt /ruleset:=Tools\FxCopRuleSet\CompagnyRules.ruleset /ignoregeneratedcode

Note that more than 100 violations in Assembly1.dll are detected.

The rules that cause violations are: AvoidUninstantiatedInternalClasses, AvoidUncalledPrivateCode, AvoidUnusedPrivateFields, TypeNamesShouldNotMatchNamespaces

So this is not related to relations between different assemblies. The only solution I found to automate it in TeamCity properly is to use a nant script that calls fxcopcmd.exe on the different assemblies one by one and output the results in different files.

Any ideas are welcome!

Thanks.

hunch_hunch
  • 2,283
  • 1
  • 21
  • 26
Sebastien Filion
  • 94
  • 1
  • 5

1 Answers1

1

It sounds like Assembly1.dll probably has InternalsVisibleToAttribute instances that make friend assemblies out of some subset of the other assemblies listed in the example 4 command line.

When FxCop is run for an assembly with friend assemblies that aren't also included in the run, these rules aren't able to tell whether there might be code in the friend assemblies that invokes code within the target assembly that wouldn't be otherwise invoked, and it gives you the benefit of the doubt (i.e.: doesn't flag violations that might be false positives). However, when you run with a complete set of friend assemblies, the rules can make that determination, and you will see violations flagged for non-public code that isn't invoked from within either the assembly itself or its friend assemblies.

BTW, you wouldn't see the violations from within Visual Studio since it executes FxCop separately for each project.

Nicole Calinoiu
  • 20,843
  • 2
  • 44
  • 49
  • Thank you for the explanation. To prevent any differences between FxCopCmd.exe and VS2013 Code Analysis, I strongly recommend to launch the fxCopCmd.exe separately for each project. By doing this, we always get the same results! This topic could be mark as fixed. – Sebastien Filion Oct 08 '14 at 13:24