Scanning single project in .NET solution with multiple projects using SonarQube

Question

I have the following issue.

We have a .NET solution which contains several projects and have created a VSTS build definition per project because we don't want to build the entire solution every time there's a change in one of the individual projects.

Of course in this case when using SonarQube we would only want to push the metrics of that particular project / buildefinition to the SonarQube server and not of the entire solution. By default the latter is what's happening and that is what we want to change.

We are using VSTS with Visual Studio 2015, SonarQube plugin version 4.1.1 and SonarQube version 6.7 (build 33306). The buildagents are running on Windows 8.1 at this time.

Example solution structure:

MainSolution

• ProjectA
• ProjectB
• ProjectC

The root sources directory for VSTS in this case is C:\\buildagent\\vsts-agent\\_work\\19\\s

Directory structure on build agent would look like this:

C:\buildagent\vsts-agent\_work\19\s\ProjectA
C:\buildagent\vsts-agent\_work\19\s\ProjectB
C:\buildagent\vsts-agent\_work\19\s\ProjectC

Let's say we have a VSTS build definition for ProjectB which only builds ProjectB. In that case we only want to SonarQube to scan the contents of the ProjectB project.

I've tried several things to accomplish this but none of them worked.

1. sonar.inclusions / sonar.exclusions Only seems to work on file level, not directory or project. Tried several settings and no error occurs but everything is ignored by the scanner which results in nothing being pushed to SQ server at all.

2. sonar.sources

Setting the property sonar.sources to C:\\buildagent\\vsts-agent\\_work\\19\\s\\ProjectB looked promising but we got the error message below when running the scanner:

2018-04-04T07:12:51.0538120Z INFO: Base dir: C:\\buildagent\\vsts-agent_work\\19\\s 2018-04-04T07:12:51.0538120Z INFO: Working dir: C:\\buildagent\\vsts-agent_work\\19.sonarqube\\out.sonar 2018-04-04T07:12:51.0538120Z INFO: Source paths: ProjectB 2018-04-04T07:12:51.0548120Z INFO: Source encoding: windows-1252, default locale: nl_NL 2018-04-04T07:12:51.1518136Z ERROR: Error during SonarQube Scanner execution 2018-04-04T07:12:51.1518136Z ERROR: File ProjectB/App.config can't be indexed twice. Please check that inclusion/exclusion patterns produce disjoint sets for main and test files

It looks like SonarQube is trying to index ProjectB twice. Once with BaseDir set to C:\\buildagent\\vsts-agent\\_work\\19\\s\\ProjectB and once with BaseDir set to C:\\buildagent\\vsts-agent\\_work\\19\\s

3. sonar.projectBaseDir

When setting the property sonar.projectBaseDir to C:\\buildagent\\vsts-agent_work\\19\\s\\ProjectB we receive below error from SonarQube.

2018-04-04T07:00:51.2906744Z ERROR: Error during SonarQube Scanner execution 2018-04-04T07:00:51.2906744Z ERROR: Dir C:\\buildagent\\vsts-agent_work\\19\\s\\ProjectA should be relative to project baseDir

It looks like it is still trying to scan the entire VSTS root source directory C:\\buildagent\\vsts-agent\\_work\\19\\s and not just C:\\buildagent\\vsts-agent\\_work\\19\\s\\ProjectB .

So the question remains. How can we make this work?

Answer 1

SonarQube doesn't support updating only some of the metrics in a SonarQube project - if you have MSBuild projects A, B and C that are all built in a solution and pushed to SonarQube X, then you can't then just build A and push its updated metrics.

You have a couple of options:

• don't run analysis as part of your per-MSBuild-project VSTS build definitions. Instead, run a nightly build of the whole solution and run the analysis as part of that build.
• push each MSBuild project to a separate SonarQube project. That would allow you to push metrics on each build, but you'd lose the aggregated view over your projects. If you are using the Enterprise Edition of SonarQube then you could use the Portfolio Management feature to get a consolidated view over those SonarQube projects.

Answer 2

We've made the decision to split up solutions with multiple projects into multiple solutions and base our VSTS build definitions on single solutions instead of projects. That is probably the best approach.