.NET 2.0 SDK directory

sonar.dotnet.2.0.sdk.directory

C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727

Absolute path of the .NET SDK 2.0 directory.

.NET 3.5 SDK directory

sonar.dotnet.3.5.sdk.directory

C:/WINDOWS/Microsoft.NET/Framework/v3.5

Absolute path of the .NET SDK 3.5 directory.

.NET 4.0 SDK directory

sonar.dotnet.4.0.sdk.directory

C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319

Absolute path of the .NET SDK 4.0 directory.

.NET version

sonar.dotnet.version

4.0

Default version of the .NET framework that must be used.

Silverlight 3 assembly directory

sonar.silverlight.3.mscorlib.location

C:/Program Files/Reference Assemblies/Microsoft/Framework/Silverlight/v3.0

Location of the core assembly for Silverlight 3 framework.

Silverlight 4 assembly directory

sonar.silverlight.4.mscorlib.location

C:/Program Files/Reference Assemblies/Microsoft/Framework/Silverlight/v4.0

Location of the core assembly for Silverlight 4 framework.

Silverlight version

sonar.silverlight.version

4

Default version of the Silverlight framework that must be used.

Test project names

sonar.donet.visualstudio.testProjectPattern

*.Tests

Pattern that check project names to identify unit test projects. Multiple patterns may be specified using semicolon as a delimiter.

Pattern that check project names to identify integration test projects. Multiple patterns may be specified using semicolon as a delimiter. If there is no pattern specified, unit test patterns are used.

Solution to analyse

sonar.dotnet.visualstudio.solution.file

Relative path to the ".sln" file that represents the solution to analyse. If none provided, a ".sln" file will be searched at the root of the project.

Exclude generated code

sonar.dotnet.excludeGeneratedCode

true

Set to false to include generated code like 'Reference.cs' files or '*.designer.cs' files.

Build configuration

sonar.dotnet.buildConfiguration

Debug

Not needed in most cases.
The build configurations used to build the solution and which will be used to locate the assemblies during the sonar analysis. To ease the configuration when using the "maven dotnet plugin", several values may be specified separated by colons or semi-colons as in "Debug,Release". The sonar plugins use only one value. "Debug" is chosen if present otherwise the first one is picked. Anyway, it is strongly recommended to run a standard debug compilation build prior to any sonar analysis. This is because code compiled in release mode is optimized and some tools such as Mono Gendarme will not be able to find as many violations as they will with debug code.

Assemblies to scan (since v1.1)

sonar.dotnet.assemblies

Not needed in most cases.
Comma-seperated list of path patterns to locate the assemblies of the current visual studio solution. If empty, the plugin will try to get this list from the Visual Studio 'csproj' files. These paths can be absolute or relative, the starting point being the folders where the csproj files are located. Also the special expressions such as "$(SolutionDir)" can be used to build a path relative to the root folder of the solution (i.e. where the sln file is located). If the build process runs a msbuild/nant script just after the compilation that copies the generated assemblies to a "BUILD" directory, you can use something like that:

$(SolutionDir)/BUILD/$(AssemblyName).$(OutputType)

Tools such as FxCop and Gendarme that work on compiled code are executed once per project. Hence the above pattern will be evaluated for each project of the solution using the proper values of "AssemblyName" and "OutputType" expressions.

Do not use this property unless you have no choice

Set this property to value "safe" if you encounter any "NonUniqueResultException" error as described in this thread.
Setting this property to "safe" allows to safely analyse several solutions that share and import the same Visual Studio projects.