Part of dotnet/arcade#13315
The following packages reference 4.3.x BCL packages and with that bring in the netstandard1.x dependency graph. See the linked issue for why this is undesirable.
- Microsoft.Bcl.Cryptography -> System.Security.Cryptography.Algorithms/4.3.1
- Microsoft.Extensions.DependencyModel -> System.Runtime.InteropServices.RuntimeInformation/4.3.0
- Microsoft.Extensions.FileProviders.Physical -> System.Security.Cryptography.Algorithms/4.3.1
- Microsoft.Extensions.Hosting -> System.Runtime.InteropServices.RuntimeInformation/4.3.0
- Microsoft.Extensions.Logging.Console -> System.Runtime.InteropServices.RuntimeInformation/4.3.0
- System.Security.Cryptography.Cose -> System.Security.Cryptography.Algorithms/4.3.1
The ones that reference System.Runtime.InteropServices.RuntimeInformation are .NET Framework builds. It should be fine for that codebase to assume that it runs on .NET Framework Windows only.
The libraries that reference System.Security.Cryptography.Algorithms use it internally without exposing its API and only use the IncrementalHash type. It might be possible to add down-level support via compiling type into those builds to avoid the dependency.
cc @dotnet/area-extensions-hosting @dotnet/area-system-security @dotnet/area-extensions-logging @vcsjones
Part of dotnet/arcade#13315
The following packages reference 4.3.x BCL packages and with that bring in the netstandard1.x dependency graph. See the linked issue for why this is undesirable.
The ones that reference
System.Runtime.InteropServices.RuntimeInformationare .NET Framework builds. It should be fine for that codebase to assume that it runs on .NET Framework Windows only.The libraries that reference
System.Security.Cryptography.Algorithmsuse it internally without exposing its API and only use theIncrementalHashtype. It might be possible to add down-level support via compiling type into those builds to avoid the dependency.cc @dotnet/area-extensions-hosting @dotnet/area-system-security @dotnet/area-extensions-logging @vcsjones