views:

303

answers:

3

On a Windows Server 2003 R2 with .NET 4 SDK but without Visual Studio 2010, I have tried building a Visual Studio 2010 solution with

msbuild MySolution.sln /p:RunCodeAnalysis=true

but that fails.

What is required to run code analysis on such an environment?


I get this error message:

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\CodeAnalysis\Microsoft.CodeAnalysis.targets(129,9): error MSB6003: 
The specified task executable "FxCopCmd.exe" could not be run. 
Could not load file or assembly 
'Microsoft.VisualStudio.CodeAnalysis.Sdk, Version=10.0.0.0, Culture=neutral, PublicKeyToken= b03f5f7f11d50a3a' 
or one of its dependencies. 
The system cannot find the file specified.

I have installed FxCop from the SDK and without luck pointed the variable FxCopDir to the installed location of FxCopCmd.exe, and also setting this registry entry to that location:

HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\10.0\Setup\EDev@FxCopDir
A: 

Another option might be calling FxCop executable as a build task (from msbuildtasks), saving the result as an XML file that can be parsed within most of the CI tools (like Hudson and CC.NET)

alexandrul
+3  A: 

I had the same problem on my MSBuild server and fixed it by:

  • Installing Windows SDK 7.1
  • Setting up the registry keys FxCopDir and StanDir in HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\10.0\Setup\EDev (in Win32).

I then needed to copied over to the FxCop folder on the build server, from the dev PC:

  • The folder Rule Sets
  • Microsoft.VisualStudio.CodeAnalysis.Sdk.dll
  • Microsoft.VisualStudio.CodeAnalysis.Phoenix.dll
  • phx.dll

Do a search for them on your dev PC with Visual Studio installed to locate them.

Then use the .NET 4.0 version of gacutil.exe to install Microsoft.VisualStudio.CodeAnalysis.Sdk.dll to the GAC.

You should then be able to run code analysis as part of an MSBuild build and have it work properly.

GiddyUpHorsey
Thanks! Including these assemblies and rules made it work for me.
Ole Lynge
A: 

An alternative to FxCop would be to use NDepend and its Code Query language (CQL). CQL is dedicated to write code quality rules that can be verified live in Visual Studio, or that can be verified during build process and reported in a HTML report. Here are a few samples of CQL rules (designed to be highly customizable):

Code refactored recently should be 100% covered by test:

WARN IF Count > 0 IN SELECT METHODS WHERE CodeWasChanged AND PercentageCoverage < 100

Complex methods should be commented:

WARN IF Count > 0 IN SELECT METHODS WHERE CyclomaticComplexity > 15 AND PercentageComment < 10

I don’t want that my User Interface layer to depend directly on the DataBase layer:

WARN IF Count > 0 IN SELECT NAMESPACES WHERE IsDirectlyUsing "DataLayer" AND NameIs "UILayer"

Static fields should not be named m_XXX (Custom naming conventions):

WARN IF Count > 0 IN SELECT FIELDS WHERE NameLike "^m_" AND IsStatic

Methods out of MyAssembly and MyAssembly2 should not have more than 30 lines of code:

WARN IF Count > 0 IN SELECT METHODS OUT OF ASSEMBLIES "MyAssembly1", "MyAssembly2" WHERE NbLinesOfCode > 30

Public methods should not be removed to avoid API breaking changes:

WARN IF Count > 0 IN SELECT METHODS WHERE IsPublic AND IsInOlderBuild AND WasRemoved

Types tagged with the attribute MyNamespace.FullCoveredAttribute must be thoroughly covered by tests:

WARN IF Count > 0 IN SELECT TYPES WHERE HasAttribute "MyNamespace.FullCoveredAttribute" AND PercentageCoverage < 100

Patrick Smacchia - NDepend dev