Azure DevOps pipeline build fails with SonarCloud and Source Generator

SonarQube Cloud
, ,
1

Hi,

We use some source generators (local projects added as analyzer project references to the consuming projects) and our Azure DevOps CI pipeline (YAML) builds started failing because the source generators started throwing a TypeInitializationException exception.

There were no code changes to the source generator between successful and failing builds and if the SonarCloud tasks are removed from the pipeline the build works again, the solution also builds locally for all of the devs.

From the logs of the SonarCloudPrepare@1 task I can see that C# analyzer was updated between successful and failing builds from version 8.24.0.32949 to 8.25.0.33663.

I have also tried both Windows and Ubuntu agents and have the same results, with SonarCloud the build fails without and it succeeds.

Versions

SonarCloud Azure Devops extension v1.24.0
Task Prepare Analysis Configuration v1.20.0
C# Sonar Roslyn Analyzer v8.25.0.33663

2

I have added a minimal repro here:

This has the same behaviour where the build succeeds locally and in DevOps without SonarCloud but fails in DevOps with SonarCloud. Although with this repro the exception is different as it throws a FileNotFoundException with the message Could not load file or assembly 'Newtonsoft.Json...'

3

Hi @Aquila_Sands

Both UseDotnet CLIs that you have cannot be put one after the other. I would suggest to let only the UseDotnet version 2.1, then do the SonarCloudPrepare, then if you want move back to .NET 5 for restore and build.

Please note also that you will need the SonarCloudAnalyze task after the build.

HTH,
Mickaƫl

4

Hi @mickaelcaro,

Thanks for taking a look at this. Iā€™ve tried your suggestion unfortunately moving the UseDotNet task had no effect. Also the same issue occurs on a Windows agent with only 1 UseDotNet task as the first one is for the runtime only which is not needed on a Windows agent.

Also yes, I am aware that an analysis task is needed :slight_smile: but I left it out for the repro because the pipeline never gets that far.

5

Can you maybe share the logs of the whole build please ? Preferably in debug mode (you can add the system.debug=true pipeline variable.

Thank you

6

Sure. Iā€™ve attached logs from a failing build and also a build without the SonarCloud prepare task that works.
no.sonarcloud.build.works.logs.zip (87.7 KB)
sonarcloud.build.fails.logs.zip (115.3 KB)

Thanks

7

Hi @Aquila_Sands

Can you try adding the following line to your Generator project ?

<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>

Let me know.
Thanks

8

No, that didnā€™t work.

11

My colleague is now experiencing the same issue on a local install of SonarQube, sonarqube-8.9.1.44547 works and sonarqube-9.0.0.45539 fails.

We have also notice that this PR added a reference to Newtonsoft.Json to the analyzer:

Could it be possible that this is causing the issue? We have tried downgrading the version of Newtonsoft.Json we reference to match that used in the analyzer but the build still fails.

12

@Aquila_Sands does the build succeed if you disable rule S2115 in the Quality Profile, or does it fail with the previous error?

13

Hi @duncanp, it still fails with the same error.

14

@Aquila_Sands I think there are two separate errors: one related to the NewtonSoft.Json.dll version mismatch, one not.

Iā€™ve created a PR for info.

If I change the generator to use the same version of NewtonSoft then build with MSBuild, the build works locally.
If I build with dotnet, it fails with a FileNotFoundException for System.Security.Permissions, Version=0.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51. I havenā€™t worked out why.

Do you get the same behaviour?

15

@duncanp yes I do get the same behaviour.

This is just a guess but could this issue be because the Newtonsoft.Json reference in SonarAnalyzer.CSharp.csproj needs the PrivateAssets="all" attribute?

I do think this should be raised as a bug in the relevant Sonar Source repository though as it should not be necessary to make these kinds of changes in order to fix a previously working build especially when added to the fact that the standard dotnet cli task fails.

23

Hi @Aquila_Sands,

Thanks a lot for the details and for creating the reproducer project. Indeed, the problem seems to be related to our dependency on Newtonsoft.Json.dll.

Iā€™ve created an issue on our side to take care of that.

1 Like
24

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.