System.Interactive.Async: consume Microsoft.Bcl.AsyncInterfaces for all suitable TFMs

[mgravell]

Currently the build targets defines this via:

 Condition="'$(TargetFramework)' == 'netcoreapp3.0' or '$(TargetFramework)' == 'netstandard2.1' or '$(TargetFramework)' == 'netstandard2.0'"

However, the Microsoft.Bcl.AsyncInterfaces package provides these for other TFMs (preview, waiting on .NET Core 3). If the APIs aren't unified, it is going to cause confusion for consumers, especially if they take transitive dependencies via any path that gives them both Microsoft.Bcl.AsyncInterfaces and System.Interactive.Async on any of the impacted TFMs.

Ultimately, having two sources of truth for these APIs is just a disaster for consumers. The extern alias hack exists, but is a pain to explain to users - who expect install-package to just work.

I would argue that Microsoft.Bcl.AsyncInterfaces is a more "official" source of truth than System.Interactive.Async (despite System.* vs Microsoft.*), and thus System.Interactive.Async must yield.

To repeat my analysis from here, the most likely outcome is:

• .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)

(with a slightly simpler setup possible if we can collectively convince Microsoft to not omit any TFMs that System.Interactive.Async targets)

There is a knowledge gap (for me) here about what happens if MonoTouch1.0, for example, targets both (directly or indirectly); there is an explicit TFM for this in Microsoft.Bcl.AsyncInterfaces, but if "reactive" ends up providing the .NET Standard 1.0 or .NET Standard 1.3 build: the problem is back. If that is the case, I would say that it provides grounds for either:

1. we lean on Microsoft.Bcl.AsyncInterfaces to provide net46, net45, netstandard1.0 and netstandard1.3 TFMs, and remove the interfaces completely from System.Interactive.Async
2. "reactive" should provide explicit TFMs for everything that Microsoft.Bcl.AsyncInterfaces provides TFMs for (type-forwarding to Microsoft.Bcl.AsyncInterfaces), to ensure no danger zones

My preferred option is "1", and IMO the risk of customer/consumer impact by continuing to have multiple definitions should be a fair battering ram for adding them. That would allow the cleaner:

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

which doesn't have any danger zones for transitives, since all "reactive" TFMs are provided for by the "official" sources.

Happy to try and help with a PR on the local changes if you think this unification is the way to go.

[mgravell]

Oh! I've just noticed that the latest preview of System.Interactive.Async reduces the TFM surface; in which case it becomes easier:

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

(and remove from "reactive" source)

and only System.Interactive.Async is impacted; we might not need to wrestle the Microsoft.Bcl.AsyncInterfaces into adding TFMs if this is the plan

[mgravell]

Huh, OK, now I'm even more confused; it looks like this already happened

I'm kinda confused how the "Dependencies" tree on nuget is empty (which is what ultimately confused me), but... who am I to question the nupkg wizards!

[mgravell]

huh... so, yeah, I figured it out; the interface actually comes from System.Linq.Async, which has the dependencies. So... all good, it looks like you've already covered all bases. I'll shut up now.

[jzabroski]

I'm kinda confused how the "Dependencies" tree on nuget is empty (which is what ultimately confused me), but... who am I to question the nupkg wizards!

I know this is off-topic, but have you ever figured out how the nuget dependencies tree on nuget works?

I always assumed I was simply behind the curve on how .NET Core thought about packaging, but the more I learn and the more certain I become, the more convinced I am that there are bugs in how nupkg is built via dotnet pack/publish. I can't figure out how my own packages say they have zero dependencies.