One of our PR builds (Azure DevOps Pipeline) recently started failing even though no meaningful code had changed in the repository. Through a process of elimination, we found that the “SonarCloudPrepare” task in the build YML seems to be causes the failure. If we disable it, everything works as expected. If we turn it back on, the build task fails with the follow set of errors:
Error CS0104: ‘Func<>’ is an ambiguous reference between ‘System.Func’ and ‘System.Func’
Error CS0104: ‘Task<>’ is an ambiguous reference between ‘System.Threading.Tasks.Task’ and ‘System.Threading.Tasks.Task’
Error CS0104: ‘TimeSpan’ is an ambiguous reference between ‘System.TimeSpan’ and ‘System.TimeSpan’
Error CS0104: ‘Task<>’ is an ambiguous reference between ‘System.Threading.Tasks.Task’ and ‘System.Threading.Tasks.Task’
Error CS0104: ‘TimeSpan’ is an ambiguous reference between ‘System.TimeSpan’ and ‘System.TimeSpan’
Below is some information about our build and what we have found to this point:
Azure DevOps pipeline build
.NET solution, containing multiple framework versions. Ranging from .NET 4.6.2 - .NET 6.0. It is worth noting that the project the build errors are thrown in is a .NET 6.0 project.
Built using the Visual Studio Build Task (VSBuild)
Runs on a standard MS Windows Server 2022/VS 2022 build agent
First occurrence of the issue coincides almost exactly with the release of version 5.4.0 of “SonarScanner for Azure DevOps” and the corresponding release of the updated ADO task (1.2.6)
We have tried manually specifying the previous version of the ADO task (1.25.1), but it appears that this still downloads the latest versions of the “SonarAnalyzer” packages 8.36.0.43782
Is it possible to force the ADO task to use a previous version of the “SonarAnalyzer” packages in order to confirm that the issue was introduced with new version?
This version of the analyzer has been deployed to SonarCloud on 2022-02-23.
Could you please share the verbose MSBuild logs with us?
Can you narrow the problem down to one single project? You could try to use the NuGet in that project with various versions to see if it’s related to its version NuGet Gallery | SonarAnalyzer.CSharp 9.12.0.78982
The build always fails on the same project, same class. The class in question is very simple, containing 24 lines total, 10 of which are meaningful. The only external dependency in this class is the LazyCache package, which is a wrapper around the Microsoft.Extensions.Caching.Memory package.
I have tried adding the packages to the solution in order to reproduce the issue locally, but it builds fine. Based on what I can tell from the logs in the “prepare for analysis” task in ADO, it downloads the latest version of the SonarAnalyzer package(s) for use in the build. If a different version of the packages are referenced directly in the project, does it use that version instead during build?
The first occurrence of the issue happened on 2-17. We had one successful build on version 1.26 of the task on 2-16 at 11:42 AM EST, then it started failing. What is odd is that probably about 1 out of every 10 builds will still succeed. What originally led me down the path of suspecting it was the SonarCloud task was this message in the logs of what of the successful builds. It seems like when this issue occurred, the analysis would not happen, and the build would succeed.
CompilerServer: server failed - server rejected the request due to analyzer / generator issues ‘analyzer assembly ‘C:\Users\VssAdministrator\AppData\Local\Temp.sonarqube\resources\2\System.Buffers.dll’ has MVID ‘36e84b0d-9d74-4086-a062-54e1963f24d5’ but loaded assembly ‘System.Buffers, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51’ has MVID ‘f389ca43-32bf-4e24-ad8c-a6ed5efddff3’, analyzer assembly ‘C:\Users\VssAdministrator\AppData\Local\Temp.sonarqube\resources\2\System.Numerics.Vectors.dll’ has MVID ‘95de52ab-0179-450a-9f6f-08d224d60b15’ but loaded assembly ‘System.Numerics.Vectors, Version=4.1.4.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ has MVID ‘34905ed1-db9d-4250-b31b-b80e1ff70ff5’, analyzer assembly ‘C:\Users\VssAdministrator\AppData\Local\Temp.sonarqube\resources\2\System.Runtime.CompilerServices.Unsafe.dll’ has MVID ‘bd600ba8-23b5-4d45-ba63-f24457fa3be3’ but loaded assembly ‘System.Runtime.CompilerServices.Unsafe, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ has MVID ‘9dde2c5e-b52a-4cbd-861e-9aacf36593ce’’ - f61e50d1-281a-43c2-bf0c-323534282bdc
I’m having this problem too! It’s annoying because the analysis fails intermittently.
The message I get is:
/home/adminuser/agent/agent-1/_work/6/s/DTF.Issuing.BarcodeMicroservice.Entities/BaseEntity.cs(14,16): error CS0104: 'DateTime' is an ambiguous reference between 'System.DateTime' and 'System.DateTime' [/home/adminuser/agent/agent-1/_work/6/s/DTF.Issuing.BarcodeMicroservice.Entities/DTF.Issuing.BarcodeMicroservice.Entities.csproj]
/home/adminuser/agent/agent-1/_work/6/s/DTF.Issuing.BarcodeMicroservice.Entities/BaseEntity.cs(19,16): error CS0104: 'DateTime' is an ambiguous reference between 'System.DateTime' and 'System.DateTime' [/home/adminuser/agent/agent-1/_work/6/s/DTF.Issuing.BarcodeMicroservice.Entities/DTF.Issuing.BarcodeMicroservice.Entities.csproj]
Something similar happens to me. First fail detected 18th February. In my case it marks an error:
error CS0104: 'IEnumerable<>' is an ambiguous reference between 'System.Collections.Generic.IEnumerable<T>' and 'System.Collections.Generic.IEnumerable<T>'
It happens both, in Azure Devops using the sonar cloud taks and locally using dotnet-sonarscanner. It doesn’t happen all the time but about less than half of the compilations. Project is in net6
I had not tried reproducing the issue locally using dotnet-sonarscanner. I will give this a try. Should make it much easier to narrow down the source of the issue.
We are also facing this issue recently.
Apparently it only hits System types:
error CS0104: 'Guid' is an ambiguous reference between 'System.Guid' and 'System.Guid'
error CS0104: 'Task<>' is an ambiguous reference between 'System.Threading.Tasks.Task<TResult>' and 'System.Threading.Tasks.Task<TResult>'
We are using SonarScanner for MSBuild 5.3.2 from ADO task version 1.22.0.
Thank you all for the updates on this thread. I apologize for the late answer. I didn’t see obvious issues in the logs.
We will need more of your help to diagnose this.
Some events around that time:
2022-02-17 13:34:10 UTC - this is when sonar-security-csharp-frontend-plugin-9.4.0-M1.15235.jar was deployed. This is used for our security offering. @patrick.elmore Do you have a way to verify if the issues started to occur after this date?
On 2022-02-15, Visual Studio 2022 version 17.1.0 got released, and this is what you are using: MSBuild version = "17.1.0+ae57d105c". Was the last successful build using a previous version, i.e 17.0.0?
Regarding the possibility that this issue started manifesting itself with MSB 17.1.0 :
If you use the previous version of VS2022 in your CI, will it work?
Can you reproduce it locally with 17.1.0? If yes, can you share the repro project with us (privately if needed)?
If using VS 2022 17.0.0 doesn’t fix the issue, could you exclude the project that fails from the analysis, as a temporary mitigation and to unblock your pipelines?
<PropertyGroup>
<!-- Exclude the project from analysis -->
<SonarQubeExclude>true</SonarQubeExclude>
</PropertyGroup>
@Jose_Luis_Latorre_Mi@nnotario@rbgarcia@leod could you please check the logs and see if you’re building with MSBuild 17.1.0, and try and use MSBuild 17.0.0 instead, to see if this is truly the case?
@Andrei_Epure It will take a some time to do some of the troubleshooting steps requested, but here is the info you requested I can give you right away.
The first occurrence of the issue was February 17, 18:30 UTC. The build prior to the that was successful, and it ran on February 16, 16:43 UTC.
We have failed builds using two versions of the windows-2022 VM image. On has MSBuild 17.0.x, the other has 17.1.x. Images in question 20220207.1 and 20220227.1.
Based on the VM image information above, this does not appear to be a direct result of MSBuild 17.1
We had come across this in another unrelated thread and attempted adding it to the project in question. The issue continued to persist.
I have not run dotnet-scanner locally, but I will give it a try and post the results once complete.
I hadn’t noticed the difference between msbuilds. However, I can confirm that when I reproduce it locally, it’s using MSB 17.0.0+c9eb9dd64 while when it fails in CI it’s using 17.1.0+ae57d105c
I have to check internally about sharing the repo.
Thanks for the updates @nnotario and @patrick.elmore - it helps narrow down some of the possible causes, although we still haven’t managed to repro this locally yet, unfortunately.
@patrick.elmore, I noticed from the logs that the project that is failing to build has C# langversion set to preview.
Is it possible to change the version to latest to see if that makes a difference?
Do you know which preview feature(s) the project is using?
@duncanp These builds were out of a branch I created to test different changes in an attempt to fix the build. I had set it to preview at one point, and never reverted it. I will set it back since it didn’t resolve the issue, but we have run many build where the LangVersion property is not explicitly set, and the build still fails.
I think this has something to do with global using statements in C# 10/.NET 6. I tried explicitly setting the LangVersion to latest for all projects targeting .NET 6.0. When the build ran I got a very similar build error, but in a different .NET 6.0 project. When updating the LangVersion, I noticed the ImplicitUsings properties in the project files. This made me wonder if MSBuild was somehow getting tripped up by this. Seemed like a reasonable thing to take a shot at since if it were somehow “double referencing” assemblies included in the the global using statements (ex. System), it would lead to it not being able to figure out types like System.TimeSpan.
I went through the projects in question, removed the ImplicitUsings properties, fixed the large number of errors resulting from this change, and re-ran our build. At this point I have run 6 builds in a row successfully. I have ran numerous builds trying to get this work and would occasionally get one build that went through for some reason. I couple of times I saw 2 in a row go through, but never more than that.
Everyone else in the thread having this issue, I assume you are also seeing this error in relation to projects targeting .NET 6. Try removing/disabling the ImplicitUsings property in your project files and fixing the resulting errors by adding the appropriate using statements to the classes in question. Please post your results here regardless of whether it works or not to help @Andrei_Epure and @duncanp narrow down the root cause.
@patrick.elmore thanks for the additional detail. ImplicitUsings sounds like an promising line of enquiry.
FYI we have managed to repro the issue locally, albeit intermittently. The repro repo is here - it’s a .NET6 class library with half-a-dozen lines of code and lots of NuGet packages.
I suspect this is indeed related to ImplicitUsing. I kept mine enabled but removed unnecessary using statements from the top of the files. It seems to have helped, I want to run a few more times to be sure.
@leod thanks for the pointer to the StackOverflow issue. There’s no mention of Sonar analyzers being used in that case, so it might be a more general problem with assembly resolution/conflicts, with the Sonar analyzers just happening to have whatever characteristic it is that triggers the issue.
FYI we compared the arguments passed to the compiler in the failing and non-failing cases and they are identical. This suggests the problem is more likely to be in the compiler than MSBuild or the SonarScanner for .NET.
I checked the Roslyn repo on GitHub last week to see if this is known issue, but didn’t find anything (initially this issue sounded promising, but it’s about types in different namespaces).
