Add TaskAsyncEnumerableExtensions to Microsoft.Bcl.AsyncInterfaces

[stephentoub]

Adds the remaining types needed for the Microsoft.Bcl.AsyncInterfaces package
Blocked on #37367
Contributes to #37354
cc: @terrajobst, @joperezr

[joperezr]

Changes here LGTM

[stephentoub]

@joperezr, it looks like this is configured to build against netstandard and netstandard2.1. netstandard2.1 doesn't yet contain these APIs, so the ref TypeForwardedTo is failing to compile. What's the right way for me to deal with this now? Should I hold off until @terrajobst adds these for netstandard2.1, and then presumably we'd pull in those updated refs and things would just start working?

[joperezr]

I see, in this case for the ref, we can do two different approaches. We can either have that TypeForwardedTo in the Forwards.cs file moved to a different file that gets includded when not building for netstandard2.1, or an easier way would be to simply set the Ignore missing types property on the project when building for netstandard2.1 like:

<PropertyGroup Condition="'$(TargetGroup)' == 'netstandard2.1'">
  <GenFacadesIgnoreMissingTypes>true</GenFacadesIgnoreMissingTypes>
</PropertyGroup>

[stephentoub]

GenFacadesIgnoreMissingTypes

If we do that, what's the functioning state of things? If you try to use this package when building against .NET Core 3.0 or .NET Standard 2.1, what will happen?

[joperezr]

If you are targetting .NET Standard 2.1 (or a compatible framework like .NET Core3.0 or UWP vNext) there is no problem, since you wouldn't be referencing those types from this contract anyway. The only problem with this, would be in the case where somebody compiled against .NET Standard 2.0 (or a compatible assembly) which would mean that they would look for the type in the M.Bcl.AI.dll but then try to run in a .NET Standard 2.1 compatible framework (other than .NET Core 3.0 since we do have the typeforward in that case) since what would happen is that the app wouldn't be able to properly find the re-route of this type to where it lives in that framework. I think that is an ok risk to take, if and only if we believe that this type will eventually (soon) be added to .NET Standard2.1, as when we eventually do it we would just remove the condition and everything will be fixed. If we are not thinking of having this type inbox in .NET Standard 2.1, then we should provide a typedef for .NET Standard2.1 for this type and a .NET STandard2.1 implementation.

[joperezr]

@stephentoub failures in the PR seem to be due to System.Data.OleDb.Tests tests failing (hanging) on some architectures. From the changes you are making, I can't see how that would be related to your PR, so in that case is it ok to go ahead and merge this or is there a reason why you might think that failures are related?

[danmoseley]

@maryamariyan the OLEDB tests are timing out, after several failures like

  System.Data.OleDb.Tests.OleDbCommandBuilderTests.DeriveParameters_NullCommand_Throws(commandType: Text) [FAIL]
      System.Runtime.InteropServices.SEHException : External component has thrown an exception.
      Stack Trace:
        D:\a\1\s\src\System.Data.OleDb\src\OleDbWrapper.cs(145,0): at System.Data.OleDb.DataSourceWrapper.InitializeAndCreateSession(OleDbConnectionString constr, SessionWrapper& sessionWrapper)
        D:\a\1\s\src\System.Data.OleDb\src\OleDbConnectionInternal.cs(94,0): at System.Data.OleDb.OleDbConnectionInternal..ctor(OleDbConnectionString constr, OleDbConnection connection)

@joperezr I have confident this should not stop you merging.

[stephentoub]

Thanks, Jose. Yeah, not related at all.

[stephentoub]

This kind of defeats the purpose of these tests, right? :)

Should we instead just exclude ConfiguredCancelableAsyncEnumerableTests.netcoreapp.cs from being included until netstandard2.1 is updated?

[joperezr]

It does defeat the purpose, but it is a temporary change, so I'm fine with either removing the tests or leaving this as is and fixing once netstandard contains the type. As you prefer.

[stephentoub]

Thanks. I prefer the excluding-these-few-tests approach.

[maryamariyan]

@maryamariyan the OLEDB tests are timing out, after several failures like

Created https://github.com/dotnet/corefx/issues/37538
I am trying to debug the failures. In the meantime I skipped all OleDb tests first to stop disrupting other PRs with this failure.

[joperezr]

Networking test failures are not related to this PR either so I'll go ahead and merge this. Thanks @stephentoub!