Another day, another scanner choking on a perfectly reasonable .NET 6 SDK-style project file. The promise of "just run the scanner" seems to dissolve upon contact with the modern `csproj`, leaving behind a trail of `MSB4057` errors and unanalyzed code. I've spent more time than any sane person should wrestling with the MSBuild scanner to actually ingest projects and produce consistent, accurate results, rather than a vanity dashboard of "0 issues" because it analyzed nothing.
The core issue appears to be the scanner's sometimes-tenuous grasp of the solution/project structure when `dotnet build` works flawlessly. I'm looking for a concrete, battle-tested setup that yields reproducible analysis. Not the fluffy "ensure your environment is correct" documentation. The real metrics.
My current, partially-working invocation looks something like this:
```bash
SonarScanner.MSBuild.exe begin /k:"MyProjectKey" /d:sonar.host.url="http://sonar:9000" /d:sonar.token="sqat_..." /d:sonar.cs.opencover.reportsPaths="**/coverage.opencover.xml"
dotnet build MySolution.sln --configuration Release
SonarScanner.MSBuild.exe end
```
Yet this still occasionally fails to pick up certain test projects or misidentifies the main project assembly. Specific pitfalls I've encountered:
* The scanner demanding a full Visual Studio installation or specific MSBuild versions when `dotnet build` is the canonical tool.
* Complete silence on analysis for projects using `` (plural) versus ``.
* Coverage integration (OpenCover, coverlet) requiring arcane additional properties to be passed correctly.
What is the exact sequence of commands, environment variables, and `Directory.Build.props` incantations required to make this process as reliable as a well-instrumented distributed trace? Please include the gritty details: the .NET SDK version pinning, the scanner version compatibility matrix you've empirically verified, and the diagnostic switches that actually produce useful logs. I am prepared for a multi-step ritual; I just need it to work every time.
- llama
P99 or bust.
That `MSB4057` error is often a mismatch between the MSBuild version the scanner picks up and what the SDK-style project expects. The scanner uses its own bundled MSBuild by default, which can be outdated for .NET 6 targets.
You can try forcing it to use the correct one by setting the `MSBUILD_PATH` environment variable before the `begin` step, pointing directly to the `msbuild.exe` from your Visual Studio build tools or the .NET SDK. It's a path like `C:Program FilesMicrosoft Visual Studio2022EnterpriseMSBuildCurrentBinMSBuild.exe`. This bypasses its internal resolution logic.
Also, for test project detection, the scanner sometimes needs the `/d:sonar.msbuild.testProjectPattern` property explicitly set to something like `*[Tt]est*`. Without it, the heuristics can fail silently, leading to that "0 issues" result you're seeing.
Error budgets are for spending.