Building with protobuf-net.grpc nuget package fails

[ogauthier]

Getting this error:
The type 'IAsyncEnumerable' exists in both 'System.Interactive.Async, Version=3.2.0.0, Culture=neutral, PublicKeyToken=94bc3704cddfc263' and 'System.Runtime, Version=4.2.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

Had to use the workaround in create an alias for System.Interactive.Async.
Is there any way to avoid that?

[mgravell]

Eesh; therein lies a story.

Short version: "no, you need that hack for now, and probably will until .NET Core 3 goes RTM"

I've added a note to the getting started docs (also linking here) which includes the hack you need to include.

---

Now the longer story...

Keep in mind that IAsyncEnumerable<T> doesn't actually formally exist anywher GA yet.

So: RX were trying to be helpful, and they added IAsyncEnumerable<T> to System.Interactive.Async - with a view to type-forwarding it on the platforms that actually support it, and providing a definition on the down-level frameworks that don't include it in the box. Sounds reasonable. They released this GA and it is in their 3.* nuget drop.

And then: the planned definition of IAsyncEnumerable<T> changed. Yeah. So; RX has a wrong definition that the C# compiler kinda hates - in a GA release. The Grpc.Core.Api library - intending to advertise something kinda akin to async enumerables (but not quite) took a dependency on RX and implemented that interface.

Separately; because I actually want to directly expose IAsyncEnumerable<T>, I'm using .NET Core 3 for the "real" IAsyncEnumerable<T>, and the more formal Microsoft.Bcl.AsyncInterfaces package (currently in preview until .NET Core 3 ships) for the down-level TFMs (netstandard2.0, net461). This means I can expose an API that actually works (always a good thing), but now there are two definitions of IAsyncEnumerable<T> in the graph (same namespace etc) - one from RX, and one the "real one". The compiler hates this (transitive dependencies all count).

So what the hack does is: it shunts the whole of System.Interactive.Async into a different namespace alias. If you don't know what a namespace alias is: normally, when you do X.Y.Foo, the compiler first looks to see if there's an X in your local scopes, otherwise it looks from the root of all the namespace trees imported; by default only global is available in any code file, so it assumes you mean global::X.Y.Foo. By default, everything goes into global. But you can define multiple namespace aliases in your reference tree - precisely for purposes like this; and different code files can allow access to different trees via the extern alias feature. By saying that System.Interactive.Async should go into the ix namespace alias and not into global, that means that we get:

if we do not have an extern alias ix; at the top of the code file

• System.Collections.Generic.IAsyncEnumerable<T> - the "right" one
• global::System.Collections.Generic.IAsyncEnumerable<T> - the "right" one
• IAsyncEnumerable<T> plus using System.Collections.Generic - the "right" one
• IAsyncEnumerable<T> plus using global::System.Collections.Generic - the "right" one

and with the explicit addition of extern alias ix; at the top of the code file:

• ix::System.Collections.Generic.IAsyncEnumerable<T> - the RX one
• IAsyncEnumerable<T> plus using ix::System.Collections.Generic - the RX one, or more likely: a compiler error that it can see two of them and has no clue which to pick
• IAsyncEnumerable<T> plus using System.Collections.Generic - the "right" one, or more likely: a compiler error that it can see two of them and has no clue which to pick
• IAsyncEnumerable<T> plus using global::System.Collections.Generic - the "right" one, or more likely: a compiler error that it can see two of them and has no clue which to pick

Since we don't actually want to consume the RX one (we just want the compiler to not break), there is almost never a reason to add extern alias ix; to your code file!

---

Long term, what I expect to happen is:

1. Microsoft will release the "real" interface in .NET Core 3 (and Microsoft.Bcl.AsyncInterfaces for back-compat)
2. RX will change their package to use type-forwarding to both of these (based on the TFM; adding the package-reference to Microsoft.Bcl.AsyncInterfaces where it is needed), and completely remove the interface from their package (unless there's a TFM that they target that Microsoft.Bcl.AsyncInterfaces does not cover); because of the interface break, this will have to be a breaking/major release (dependent on 1)
3. Grpc will remove the dependency on RX, switching to Microsoft.Bcl.AsyncInterfaces; because of the interface break, this will have to be a breaking/major release (dependent on 1, not 2)
4. protobuf-net.Grpc will update to reflect 1 and 3; in theory this would also be a breaking/major, but I expect that we'll simply not release any major until this reference mess is ironed out

So; that's my take; maybe @onovotny can confirm whether what I've assumed in 1 & 2 is correct to his understanding.

Further info on Microsoft.Bcl.AsyncInterfaces vs System.Interactive.Async; it looks like System.Interactive.Async would need:

• .NET Standard 2.1: type-forward to System.Runtime
• .NET Core 3.0 - type-forward to System.Runtime
• .NET Standard 2.0: type-forward to Microsoft.Bcl.AsyncInterfaces
• (new TFM) .NET Framework 4.6.1: type-forward to Microsoft.Bcl.AsyncInterfaces
• .NET Framework 4.6: define locally (but: correctly)
• .NET Framework 4.5: define locally (but: correctly)
• .NET Standard 1.3: define locally (but: correctly)
• .NET Standard 1.0: define locally (but: correctly)

Alternatively; we could petition Microsoft.Bcl.AsyncInterfaces to include the last 4 precisely to avoid having to define it anywhere else (this would also mean that System.Interactive.Async would not need to add a .NET Framework 4.6.1 TFM); giving:

• .NET Standard 2.1: type-forward to System.Runtime
• .NET Core 3.0 - type-forward to System.Runtime
• .NET Standard 2.0: type-forward to Microsoft.Bcl.AsyncInterfaces
• .NET Framework 4.6: type-forward to Microsoft.Bcl.AsyncInterfaces
• .NET Framework 4.5: type-forward to Microsoft.Bcl.AsyncInterfaces
• .NET Standard 1.3: type-forward to Microsoft.Bcl.AsyncInterfaces
• .NET Standard 1.0: type-forward to Microsoft.Bcl.AsyncInterfaces

What is actually happening is that System.Linq.Async (where the API actually comes from) is reducing the TFMs, and going to:

• .NET Standard 2.1: type-forward to System.Runtime
• .NET Core 3.0 - type-forward to System.Runtime
• .NET Standard 2.0: type-forward to Microsoft.Bcl.AsyncInterfaces
• .NET Framework 4.6.1: type-forward to Microsoft.Bcl.AsyncInterfaces

[mgravell]

So: I got to the bottom of it, and all the "reactive" changes already happened in the preview; so "2" in our list above is already coded, just pending on the release of .NET Core 3.0 ("1" in our list above); then we just need "3" (a "major" from Grpc) and we'll be set!

Leaving the issue open so that I remember to ... do "3"

[ogauthier]

Excellent!

[mgravell]

Fixed in current builds; the RX/IX dependency is now gone from grpc