'TimeSpan' is an ambiguous reference between 'System.TimeSpan' and 'System.TimeSpan'

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.
image

2 Likes

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.

just 2 days after Visual Studio 2022 version 17.1.0 was released and that the issue is not longer reproducible on my PC with Visual Studio 2022 version 17.1.2, could you please try to update Visual Studio to the latest version and see if the problem is reproducible?

Last week I was able to reproduce this issue with multiple versions of sonar-dotnet, even 8.29.0.36737, that was released last year and with multiple versions of the scanner, including 5.1.0 that was released one year ago.

1 Like

We also faced the issue. In our case, it was caused by global using * where * was also a normal using statement. When removing all not required using statements, the issue did not occur anymore.

2 Likes

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

<ImplicitUsings>enable</ImplicitUsings>

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.

Any news on this investigation?
Why does it happen only when Sonar Scanner is enabled?

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.

2 Likes

Thanks @duncanp I dropped a comment there.
We are experiencing this right now. The weird part is that only our test build (+sonarcloud analysis) is affected. Our docker images build just like before…

I found a solution for this, remove all the unused “Using” from the code, this should work.