Handle /errorlog:[file][,version] parameter correctly

[duncanp-lseg]

Description

The compiler parameter /errorLog now supports specifying a SARIF version i.e. the argument can be in the form <file>[,version={1|1.0|2|2.1}].

We don't handle the version parameter correctly, which prevents issues from being uploaded.

Priority: the option was added to the compiler in MSBuild v16 so it has been available for a couple of years. I haven't seen any reports users about this issue causing a problem in practice.

Repro

• create a project to analyse and explicit set ErrorLog in the project file e.g. <ErrorLog>$(MSBuildThisFileDirectory)issuesXXX.json,version=2.1</ErrorLog>

• analyse the project

Expected result

The project is analysed successfully.

Actual result

The issues are not uploaded. Also, there are no analysis warnings or errors to indicate the anything is wrong.

Additional notes

The sample project below includes the generated sonar-project.properties file, which does not contain a xxx.reportPaths property.
The sample uses VB.NET; the results are the same for C#.

ErrorLogBug.zip

[dschmittwilken]

@duncanp-sonar Any updates on this one? Or ideas for workarounds?

[pavel-mikula-sonarsource]

Hi @dschmittwilken,

I'm personally not sure if the analysis itself will actually work when using an unexpected Sarif version. You can likely trick Scanner for .NET to use the correct path by crafting some target file that will update and clean up the ErrorLog value before and after this:

sonar-scanner-msbuild/src/SonarScanner.MSBuild.Tasks/Targets/SonarQube.Integration.targets

Lines 344 to 351 in f278d0c

	<Target Name="SonarWriteProjectData" >
	<PropertyGroup>
	<SonarErrorLogExists Condition=" $(SonarErrorLog) != '' AND $([System.IO.File]::Exists($(SonarErrorLog))) == 'true' ">true</SonarErrorLogExists>
	</PropertyGroup>
	<ItemGroup>
	<SonarReportFilePath Condition= "$(SonarErrorLogExists) == 'true'" Include="$(SonarErrorLog)" />
	</ItemGroup>

It would get more tricky if you need to analyze Razor files, too.

But first, I'd suggest verifying that your Sarif version will be correctly digested by the analysis - you can replace Issues.json after the build, before the End step, inside the .sonarqube/out folder.

The interesting question is why do you need to do that?

[martin-strecker-sonarsource]

See also the community post by @dschmittwilken here https://community.sonarsource.com/t/119327

[dschmittwilken]

Hi @dschmittwilken,

I'm personally not sure if the analysis itself will actually work when using an unexpected Sarif version. You can likely trick Scanner for .NET to use the correct path by crafting some target file that will update and clean up the ErrorLog value before and after this:

sonar-scanner-msbuild/src/SonarScanner.MSBuild.Tasks/Targets/SonarQube.Integration.targets

Lines 344 to 351 in f278d0c

	<Target Name="SonarWriteProjectData" >
	<PropertyGroup>
	<SonarErrorLogExists Condition=" $(SonarErrorLog) != '' AND $([System.IO.File]::Exists($(SonarErrorLog))) == 'true' ">true</SonarErrorLogExists>
	</PropertyGroup>
	<ItemGroup>
	<SonarReportFilePath Condition= "$(SonarErrorLogExists) == 'true'" Include="$(SonarErrorLog)" />
	</ItemGroup>

It would get more tricky if you need to analyze Razor files, too.

But first, I'd suggest verifying that your Sarif version will be correctly digested by the analysis - you can replace Issues.json after the build, before the End step, inside the .sonarqube/out folder.

The interesting question is why do you need to do that?

I am not using SARIF files as input for Sonar analysis, but the presence of the line "$(MSBuildThisFileDirectory)issuesXXX.json,version=2.1" in the csproj file causes analysis errors, as described in the community post and my initial comment. We currently only use the SARIF file for Azure DevOps reports, where version 2.1 is necessary because version 1 does not support our requirements. SonarQube analysis also fails if I explicitly set version 1 in the ErrorLog setting (e.g., "$(MSBuildThisFileDirectory)issuesXXX.json,version=1.0"). Therefore, I believe this is a "csproj" file parsing issue in the SonarQube MSBuild scanner. I attempted to identify the root cause in the associated GitHub project but was unsuccessful.

[pavel-mikula-sonarsource]

It would be interesting to know what the requirements are. Having a strong need can help our product managers to understand the need and prioritize the work.

MsBuild unfortunately uses this weird hacky format of filename,version=1, instead of introducing another property for the version. Our scanner does not support that notation, as this ticket states..

[dschmittwilken]

It would be interesting to know what the requirements are. Having a strong need can help our product managers to understand the need and prioritize the work.

MsBuild unfortunately uses this weird hacky format of filename,version=1, instead of introducing another property for the version. Our scanner does not support that notation, as this ticket states..

The need is not that high, we removed Sarif Reporting in AzureDevops, but a fix or at least a warning would be very helpful also for other people not knowing what is going on in that case. Because the msbuild scanner doesn't tell you anything, but just doesn't find any C# project and just finishes silently.

If you can point me to the right direction, I can try to fix it myself and open a PR for it.

The easiest improvement perhaps can be to extend the warning you get in that case by "Root cause could also be that you are using an unsupported format in your csproj. files (e.g. comma/colon separated properties, like it is used for ErrorLog property).

Current warning we get:
“WARN: Your project contains C# files which cannot be analyzed with the scanner you are using. To analyze C# or [VB.NET](http://vb.net/), you must use the SonarScanner for .NET 5.x or higher, see [SonarScanner for .NET](https://redirect.sonarsource.com/doc/install-configure-scanner-msbuild.html)”

Proposal warning:
“WARN: Your project contains C# files which cannot be analyzed with the scanner you are using. To analyze C# or [VB.NET](http://vb.net/), you must use the SonarScanner for .NET 5.x or higher, see [SonarScanner for .NET](https://redirect.sonarsource.com/doc/install-configure-scanner-msbuild.html). Root cause could also be that you are using an unsupported format in your csproj. files (e.g. comma/colon separated properties, like it is used for ErrorLog property)”

[pavel-mikula-sonarsource]

That warning comes from the plugin. This needs to be handled by Scanner for .NET. It's not easy to tell what should happen - fail hard the build?

[dschmittwilken]

That warning comes from the plugin. This needs to be handled by Scanner for .NET. It's not easy to tell what should happen - fail hard the build?

Now I got it. The error message comes from the java plugin and the "scanner msbuild" is only the wrapper tool around. To be honest, I would fail the build because the analysis will be missing.

https://github.com/SonarSource/sonar-dotnet/blob/3a6815534e8e155e23ba393bc37118937633da79/sonar-dotnet-shared-library/src/main/java/org/sonarsource/dotnet/shared/plugins/DotNetSensor.java#L133