Google.Cloud.Firestore package causes ambiguous reference issue when used with EntityFrameworkCore

[aaronwestre]

This issue is present when referencing the Google.Cloud.Firestore package versions 2.0.0 or 2.1.0

When both Google.Cloud.Firestore and Microsoft.EntityFrameworkCore referenced, there is an ambiguity introduced for Linq-style extension methods such as Where() and OrderBy().

There are work-arounds, but this issue does not exist in earlier versions of the Google.Cloud.Firestore nuget package.

Here is a minimal diagnostic solution:

https://github.com/aaronwestre/sandbox/tree/master/libraries/googlefirestore

[jskeet]

Thank you for the report, and for including a complete example. This isn't really caused by the Firestore library directly - it's just because we have a dependency on System.Linq.Async. Even if we didn't include that dependency ourselves, many users would want to add a direct dependency on System.Linq.Async themselves, which would cause the same problem - processing an IAsyncEnumerable is simply much simpler with System.Linq.Async. (And I'd be reluctant to try to remove that dependency anyway, in terms of implementation cost.)

You can see exactly the same issue if you remove the Firestore package reference, and add a direct dependency on System.Linq.Async in your project. (There's extensive discussion of this issue here.)

The workaround of changing the using directive to using static System.Linq.Queryable; is probably the simplest one here.

I'll leave this issue open for a bit in case you have other suggestions, but I think the workaround is your best course of action here.

[aaronwestre]

Thanks for explaining @jskeet that makes sense. The Using static solution you mentioned will work.
What I was particularly confused about was why the ambiguity problem occurs with only a package reference and no "Using Google.Cloud.Firestore" statement anywhere.

[jskeet]

Right - and it's precisely because of the extra dependency, rather than any code directly in the library.

Arguably System.Linq.Async should have put its extension methods in a different namespace, but hindsight is always 2020...
I'll close this now as it sounds like we're as close to a solution as possible - i.e. the workaround + explanation.