Polyfill IAsyncEnumerable from Microsoft.Bcl.AsyncInterfaces does not work in net8.0 without reference to Microsoft.Bcl.AsyncInterfaces

[m-redding]

Description

This might be by-design because of the nature of polyfilling, but I want to understand if that's the case, and if there are any workarounds.

This is a problem in the azure-sdk-for-net repository, but I created a standalone minimal repo that demonstrates the exact issue I'm seeing because it's really difficult to explain: DependencyRepro

• BaseLibrary (represents Azure.Core)
  • BaseLibrary.csproj multi-targets netstandard2.0 and net8.0, netstandard2.0 target has a dependency on Microsoft.Bcl.AsyncInterfaces while net8.0 does not
  • AsyncPageable implements IAsyncEnumerable
• SdkLibrary
  • SdkLibrary.csproj ONLY targets netstandard2.0 and has a dependency on BaseLibrary, depends on BaseLibrary to transitively get dependency on Microsoft.Bcl.AsyncInterfaces
  • CollectionClass inherits from IAsyncEnumerable and uses AsyncPageable
• CustomerApp
  • CustomerApp.csproj net9.0 app, depends on SdkLibrary, doesn't get Microsoft.Bcl.AsyncInterfaces transitively because it uses the net8.0 target of BaseLibrary
  • Program.cs cannot use await foreach on an instance of CollectionClass unless the app adds a direct dependency on Microsoft.Bcl.AsyncInterfaces

Reproduction Steps

See repository above

Expected behavior

It would be ideal if the customer app could build without needing a dependency on Microsoft.Bcl.AsyncInterfaces

Actual behavior

Build fails with error stating that the app needs a reference on Microsoft.Bcl.AsyncInterfaces

Regression?

No response

Known Workarounds

• Adding a net8.0 target to SdkLibrary
• Keep the reference to Microsoft.Bcl.AsyncInterfaces in the net8.0 target in BaseLibrary - this is the current solution
• Adding a direct reference to Microsoft.Bcl.AsyncInterfaces in the customer app (non-solution in the real scenario as this could be breaking)

Configuration

This is not specific to any OS / .NET SDK version

Other information

No response

[huoyaoyuan]

To explain what happens:

• BaseLibrary/NS2.0 references [Microsoft.Bcl.AsyncInterfaces]IAsyncEnumerable (the polyfill), while BaseLibrary/NET8.0 references [System.Runtime]IAsyncEnumerable (The built-in version).
• When installed on higher framework, the polyfill package provides a redirection from [Microsoft.Bcl.AsyncInterfaces]IAsyncEnumerable to [System.Runtime]IAsyncEnumerable, to connect the type identities from different assemblies.
• SdkLibrary is NS2.0 only, and it exposes the polyfill interface.
• CustomerApp/NET9.0 gets direct reference to SdkLibrary, and transitive reference to BaseLibrary. Transitive references are resolved based on the top-most project, so BaseLibrary/NET8.0 is picked. Then, Microsoft.Bcl.AsyncInterfaces is not resolved as transitive dependency.

I believe the compatible framework analyzer would complain, but I'm not sure who's responsible (BaseLibrary/NET8.0 or SdkLibrary) to add the reference to Microsoft.Bcl.AsyncInterfaces.

[teo-tsirpanis]

Yes, this behavior is by design. We might need to update the READMEs of the polyfill packages to suggest that they must be referenced in all TFMs when multi-targeting and their types are used in public APIs.

Either of the first two workarounds seem OK. Multi-targeting the SDK libraries would be slightly more preferable since they will be taking advantage of some improvements in newer frameworks that are activated at compile-time (such as more efficient interpolated strings).

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

[teo-tsirpanis]

Just tested that the compatible framework analyzer does not catch this. I would suggest to open an issue in https://github.com/dotnet/sdk, or reword this issue and move it there. On further thought, considering that the analyzer would report an error in BaseLibrary, the correct solution that does not impose any requirements on downstreams is to reference Microsoft.Bcl.AsyncInterfaces in all frameworks there.

I don't think there is anything to do here. I had one idea –adding Microsoft.Bcl.* to the shared framework– but it has a couple of size and compatibility disadvantages that I don't think are proportionate to fixing a problem that occurs only when multi-targeting to .NET Standard, which is arguably a niche scenario.