Closed
Description
Azure.Core
v1.0.2 at time of writing
Azure.Core brings in Microsoft.Bcl.AsyncInterfaces which is only needed for netstandard2.0. I would recommend not putting that dependency on all downstream consumers even if they have those interfaces. The solution is to multi-target netstandard2.1 and exclude that dependency.
Activity
pakrym commentedon Jul 2, 2020
There are features coming that would require use to cross-compile to netcoreapp it would both solve this and a similar problem with System.Text.Json moving this to backlog until then.
pakrym commentedon May 11, 2021
I tried to do this and it backfired spectacularly :)
If Azure.Core only depends on
Microsoft.Bcl.AsyncInterfaces
innetstandard2.0
target the following happens:Other package libraries (I'll use Azure.Data.AppConfiguration as an example), most of which target only ns2.0, get compiled against ns2.0 target of Azure.Core. They get their
IAsyncEnumerable
type from Microsoft.Bcl.AsyncInterfaces.dll and it becomes an assembly reference.So far so good.
The problem starts when net5.0 application tries to use a client library package like that: ns2.0 target of the Azure.Data.AppConfiguration is selected along with the net5.0 target of Azure.Core. This means that no one is bringing
Microsoft.Bcl.AsyncInterfaces
into the runtime closure anymore butAzure.Data.AppConfiguration
still has an assembly reference on it. So the application fails at runtime while trying to loadMicrosoft.Bcl.AsyncInterfaces
that couldn't be found.To fix this issue we would have to cross-compile all the libraries and have an explicit reference on
Microsoft.Bcl.AsyncInterfaces
only in theirns2.0
target but we don't think doing it for one small reference is worth it right now.The very same problem is discussed in dotnet/orleans#6028 (comment)