Ah, the classic "scanner skips everything" initiation rite 😄. The advice here is gold, especially about the `dotnet clean` before the begin step. That one's saved me more times than I can count.
On the newer .NET global tool you asked about, I've tried it, and honestly, it's the same Java scanner wrapped in a dotnet CLI tool. You still get the same path resolution quirks because the heavy lifting is still that backend service. The main perk is easier installation on CI agents.
One thing that finally made it click for me was realizing the scanner *needs* a successful build *during* its begin/end session. If your `dotnet build` fails (even with a warning treated as an error), the end step will have nothing to analyze. Run your build command standalone first to make sure it's green, then run the whole scanner sequence.
it worked on my machine
Welcome to the club. This is the universal initiation rite for .NET on SonarQube. The sequence you read about is fundamentally correct, but it's basically a suggestion. The scanner is a finicky Java artifact trying to parse modern .NET projects, and it fails silently in spectacular ways.
The root cause of "skipping most of the code" is almost always that the scanner looked in the wrong `bin` directory. It guesses the output path based on MSBuild properties, and with SDK-style projects and any custom `Directory.Build.props`, that guess is often wrong. Run your begin command with the `/d:sonar.verbose=true` flag and search the log for "Project XYZ will use the following builder". That line reveals the output path the scanner *thinks* it should use. If it's pointing to some `netcoreapp3.1` folder from a past life, you have your culprit.
To fix it, you'll likely need to manually override the path using the `sonar.dotnet.build.outputPaths` property in your begin command. Point it directly at your actual `binDebugnet6.0` folders. It feels like over-engineering, but it's the only way to bridge the gap between the two worlds.
As for the missing test assemblies, that's a configuration mismatch. Your `dotnet test` command and your scanner's `sonar.cs.vstest.reportsPaths` property must agree on an absolute path. And crucially, you must run `dotnet clean` *before* the `begin` step, not after. Leftover `obj` folders from a previous build will send the scanner down a rabbit hole.
The exact commands? They'll vary, but the core is this:
`dotnet clean`
`SonarScanner.MSBuild.exe begin /k:"your-project-key" /d:sonar.dotnet.version=6.0 /d:sonar.dotnet.build.outputPaths="pathtoyouractualbinDebugnet6.0"`
`dotnet build --configuration Debug`
`dotnet test --configuration Debug --results-directory:"C:absolutepathtoresults"`
`SonarScanner.MSBuild.exe end`
It's a ritual, not a simple tool. The simpler solution would be to use a different analysis tool entirely, but if you're committed to SonarQube, this is the tax you pay.
keep it simple
That's a good point about the version flag cleaning up the pathing. I've seen the same property called `sonar.cs.version` in older docs, which adds to the confusion.
Is the `sonar.dotnet.version` setting only for the scanner's internal MSBuild discovery, or does it also change how it parses the project files?