SonarQube Extension for VSTS-TFS with C++ projects


(Brad) #1

Currently using Developer Edition v7.3, all latest plug-ins, including SonarCFamily v5.1.1 and TFVC 2.1.2. Our TFS 2017 server has the v4 extension installed.
Previously on Community Edition, scanning our primarily C# solutions. But some of them have C++ projects that we’d like to now include in the scans. Hence upgrading to Developer. But we’re having a heck of a time correlating the various snippets from the Wiki on how to get this working properly.

A typical TFS build definition will have the Prepare task, a Build task, a Test task, a Run Code Analysis task, then the Publish task. For a C#-only solution, this works.

When we now have a solution with C++ projects, the first error we got is about not being set. So, fine, in the Prepare task we add$(Build.StagingDirectory)
Now we’re past that error, except no build-wrapper-dump.json is ever created, nor any build*.log files.

The documentation ( specifically says “The extension allows the analysis of all languages supported by SonarQube”.

One of our guys playing with this managed to make one test definition work by having: Prepare Analysis, MSBuild.Begin task, a Build-Wrapper task, a Test task, an MSBuild.End task, Analysis task, then the Publish task. It appears to kinda work, but I refuse to believe that we need to go through all this pain for every solution in every build definition. There must be some subtle step/setting we’re missing.

(Massimo Paladin) #2

Hi @bpsmicro,

did you check out this page?

BTW, if you test the C/C++ analyser I would recommend you to checkout SonarCFamily v6.1.

(Brad) #3

Yes, that’s the crux of the question. The docs for the TFS extension (linked in my original) says it supports all languages. This older article talks about the old process for integrating with TFS, dated from before the new extension was released.

The question is whether the old documentation for the old method is still the only way to get this to work, and this the newer TFS extension documentation is, in fact, incorrect. And if that’s the case, do we really need seven build tasks to accomplish all this?

Thanks for pointing out the analyzer update though. I’ll do that now and see if it helps.

(Duncan Pocklington) #5

@Brad, the PrepareAnalysis step calls the Scanner for MSBuild Begin step internally and the Analysis step calls the Scanner for MSBuild End step internally. Does the analysis work if you just drop the explicit calls to Scanner for MSBuild Begin and End? i.e.

  1. Prepare Analysis: with Integrate with MSBuild selected and the build wrapper output property set as an additional property
  2. Build Wrapper step that launches MSBuild
  3. Test step
  4. Run Code Analysis
  5. (optional) Publish Quality Gate Result

(Brad) #6

Thanks for that, through careful comparison of the logs I eventually came to the same conclusion. It’s just the “Build Wrapper” annoyance to get around now, since the built-in Build Task for TFS “generates” a lot of the MSBuild options on the fly that are difficult to duplicate by hand. But there’s also the question about how important those are, so may be a moot point.
After much experimentation, I came to the realization that for the test project I was working on (not my code, another team’s), the VSTest step appeared to not be generating C++ coverage data anyway, which explained why Sonarqube wasn’t importing it. I’ve punted that info back to the responsible team to figure that part out.

I would recommend that the wiki articles for all this stuff be reviewed and possibly updated, because it’s a tad confusing/misleading. :slight_smile: