Skip to content

[FEATURE REQ] Azure.Core should also target netstandard2.1 #10326

Closed
@aidapsibr

Description

@aidapsibr

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

ghost added
needs-triageWorkflow: This is a new issue that needs to be triaged to the appropriate team.
on Mar 5, 2020
added
ClientThis issue is related to a non-management package
on Mar 6, 2020
ghost removed
needs-triageWorkflow: This is a new issue that needs to be triaged to the appropriate team.
on Mar 6, 2020
pakrym

pakrym commented on Jul 2, 2020

@pakrym
Contributor

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.

added this to the Backlog milestone on Jul 2, 2020
added
customer-reportedIssues that are reported by GitHub users external to the Azure organization.
on Sep 24, 2020
added
feature-requestThis issue requires a new behavior in the product in order be resolved.
on Oct 12, 2020
pakrym

pakrym commented on May 11, 2021

@pakrym
Contributor

I tried to do this and it backfired spectacularly :)

If Azure.Core only depends on Microsoft.Bcl.AsyncInterfaces in netstandard2.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 but Azure.Data.AppConfiguration still has an assembly reference on it. So the application fails at runtime while trying to load Microsoft.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 their ns2.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)

locked and limited conversation to collaborators on Mar 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Azure.CoreClientThis issue is related to a non-management packagecustomer-reportedIssues that are reported by GitHub users external to the Azure organization.feature-requestThis issue requires a new behavior in the product in order be resolved.

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      [FEATURE REQ] Azure.Core should also target netstandard2.1 · Issue #10326 · Azure/azure-sdk-for-net