I didn’t mention Sonar in the question as I didn’t think it was relevant. But apparently it is. We have two builds, a debug build with Sonar and a release build without. Only the debug build fails intermittently.
We have converted our code base to implicit usings. The issue is with generated files (e.g. DragonFruit, EFCore migrations) that duplicate implicit usings.
Note that resolving ambiguous references between different namespaces is not the issue here, but ambiguous references between the same namespace.
@Andrei_Epure@duncanp I have another update that could help you narrow down what exactly is going on here. Someone else on my team noticed that the class the compiler was failing on had explicit using statements in the .cs file. This is because, as noted in previous posts, this was an extremely simple class that had been lifted from another project and dropped into this one. If we removed the using statements that were being imported globally with enabled, the builds passed fine with the SonarCloud tasks enabled. This was very unexpected, so I went back and confirmed that the builds do still fail with the SonarCloud tasks enabled, and the explicit/duplicate usings in place.
To be clear, below is a screenshot of the commit that allowed the builds to succeed again. It is just removing unnecessary using statements. I can’t say that I really understand what is going on here, and why this fixes the issue, but wanted to let you guys know about this latest finding.
On my side, I was able to reproduce the issue consistently at the end of last week, and after updating all the Visual Studio versions installed (2017, 2019, and 2022), I’m no longer able to reproduce it.
Considering the fact that:
The first occurrence of the issue happened on 2-17.
Last week I was able to reproduce this issue with multiple versions of sonar-dotnet, even 126.96.36.199737, that was released last year and with multiple versions of the scanner, including 5.1.0 that was released one year ago.
Are there perhaps any updates for this issue? We’re currently in our 14d trial for SonarCloud and intend to integrate with our Azure DevOps environment. When we add the necessary steps to our build pipeline however we get this problem on code that builds fine without the SonarCloud tasks.
We’ve updated the Visual Studio Build tools on the build agent machine to no avail. We’re currently building using “SonarScanner for MSBuild 5.5.3” and “Build Engine version 17.0.0+c9eb9dd64” which I believe are the latest versions.
We have quite a few projects all of which have ImplicitUsings enabled making it a significant hassle to either remove the unnecessary duplicate usings or disable implicit usings and add them all manually.
We started seeing this error on some builds on our build server that used sonarscanner after migrating our projects to dotnet6:
Error CS0104: 'DateTimeOffset' is an ambiguous reference between 'System.DateTimeOffset' and 'System.DateTimeOffset'
I could only reproduce locally by running sonarscanner before dotnet build.
We discovered that one of the migrated csproj files had ImplicitUsing enabled
Removing that flag from the csproj file and then adding some using statements seems to have fixed the issue.
I understand it to be a bug in sonarscanner: I suspect it is detecting that the type is imported twice from the project implicit using and the using at the top of some cs class files. Maybe that is a good thing to detect, but if it is then it is not reporting it in a useful way at the moment.
Update: there appears to be some non-deterministic behaviour in the compiler itself - given the same set of inputs, it will fail intermittently with this error. The issue only appears if ImplicitUsings is enabled.
We created a minimal reproducer and opened an issue in the Roslyn repro: #60259 (apologies, I thought we had already posted the link in this thread). If you are affected by this problem, you want want to watch/comment on that Roslyn issue.
@dastevens no, we don’t have rule that detects duplicate file/implicit using statements. The error being thrown is a compiler error.