Hi, thanks for sharing this.

Are you able to share the source file and export file with me? (you can upload them through the contact form).

I don't have a way to verify or troubleshoot the behaviour of SonarScanner but I can check to see whether the details in the export file are correct.

Thanks for sending through the details. I've examined the export file in the context of the source it was generated from. To my knowledge, the export file appears to be correct and without problems. I note the following sequence points that are shown in the file for the source file triggering the error:



Note the 'sl' and 'el' (start line and end line) do not include line 23, which is specified in the error given by SonarScanner. NCrunch makes no reference to this line. However, I did notice something else interesting.

There is another method defined in the export file which has a sequence point ID that is equal to the file ID of the source file mentioned by the error message:



This method makes reference to line 23, which is perfectly valid for the method in which it refers. But it makes me suspect that there may be an issue here with how SonarScanner is parsing these IDs.

The root problem here is that the partcover export file format isn't really a published format or standard - it's just a file that gets output from another tool. We have to guess at what these fields mean, and I suppose for the developers of SonarScanner, it's the same.

My understanding is that the 'uspid' field represents the sequence point ID as specified in the assembly's PDB file. I recommend raising a support request with the developers of SonarScanner to establish their thoughts on this.

I've been posting over in Sonar about this, with no success.

However, I have managed to setup a test project & do the Sonar scan. This is when it gets weird.

If I use the Ncrunch console tool to generate the opencover.xml, sonar won't read it. If I export the opencover file from within vs2022, then it works

The steps being:
* Sonar begin
* export opencover from vs
* dotnet build
* sonar end

I diff-ed the 2 opencover file & apart from some different ordering, the files look similar. I'm not familiar enough with the files to tell the difference though.

Thanks, appreciate your input on this. My assumption was that the NCrunch addin vs the console tool would be built from the same code, so shouldn't generate significantly different files.

I'll post my my opencover files to Sonar & see what they have to say.

That's ok, I wasn't exactly clear with what I said. I've shared the 2 opencover files with you. The addin file was generated by using the export function in the Ncrunch tests window. The console file was using the console tool. Both are 4.18.0.3.

I think I've solved it.

We run the following steps because Sonar needs the code to be built with its instrumentation enabled:

Sonar start
NCrunch
.net build
sonar end

Ncrunch runs with UseBuildConfiguration config set to Release, whereas the .net build was missing that, so it built a debug release. Changing them both to be a release build seems to make it work. I'm just making sure this is true, that seems to be the problem.

There seems to also be a problem if you don't remove the output from the previous build

I suspect it's more something up with sonar. The checkout does a GIT clean -dxf, so should have removed all untracked files. Unless I tell the build server to do a clean checkout though, it fails even with the build configuration running as release. I don't think I've entirely figured out what's up with this. I can't see that's anything to do with Ncrunch though, as it's config hasn't changed on the build server & it only provides the opencover file & nunit file to sonar.