Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Jump to bottom

Avoid libraries referencing 4.3.x packages #85641

Closed
ViktorHofer opened this issue May 2, 2023 · 4 comments
Closed

Avoid libraries referencing 4.3.x packages #85641

ViktorHofer opened this issue May 2, 2023 · 4 comments
Labels
area-Infrastructure-libraries
Milestone
8.0.0

Comments

@ViktorHofer
Copy link
Member

ViktorHofer commented May 2, 2023 •
edited
Loading

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
@ghost ghost added the untriaged New issue has not been triaged by the area owner label May 2, 2023
@ViktorHofer ViktorHofer changed the title Libraries packages reference 4.3.x packages Avoid libraries referencing 4.3.x packages May 2, 2023
@ViktorHofer ViktorHofer mentioned this issue May 2, 2023
Merged
@ghost
Copy link

ghost commented May 2, 2023

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

Issue Details

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

Author: ViktorHofer
Assignees: -
Labels:

area-Infrastructure-libraries, untriaged
Milestone: -

@dotnet dotnet deleted a comment May 2, 2023
@ViktorHofer ViktorHofer added this to the 8.0.0 milestone May 2, 2023
@ViktorHofer ViktorHofer removed the untriaged New issue has not been triaged by the area owner label May 2, 2023
@tarekgh
Copy link
Member

tarekgh commented May 2, 2023

@ViktorHofer any help needed from our side or you are going to take care fixing the issues listed here?

@ViktorHofer
Copy link
Member Author

Just spoke about this in length with @ericstj and I should be able to fix these via two PRs myself. Will ask you for reviews tomorrow.

ViktorHofer added a commit to ViktorHofer/runtime that referenced this issue May 2, 2023
@ViktorHofer
Avoid S.R.I.RuntimeInformation package dependency
1754a36 
Contributes to dotnet#85641

System.Runtime.InteropServices.RuntimeInformation/4.3.0 is being
referenced in a few .NET Framework builds. The reference to that package
is undesirable as it brings in the entire netstandard1.x dependency
graph.

Instead, use System.Environment.OSVersion which returns "Microsoft
Windows NT" on .NET Framework, Mono and .NETCoreApp runtimes.
@vcsjones vcsjones mentioned this issue May 2, 2023
Merged
ViktorHofer added a commit that referenced this issue May 3, 2023
@ViktorHofer
Avoid S.R.I.RuntimeInformation package dependency (#85642)
32a16d0 
Contributes to #85641

System.Runtime.InteropServices.RuntimeInformation/4.3.0 is being
referenced in a few .NET Framework builds. The reference to that package
is undesirable as it brings in the entire netstandard1.x dependency
graph.

Instead, use System.Environment.OSVersion which returns "Microsoft
Windows NT" on .NET Framework, Mono and .NETCoreApp runtimes.
ViktorHofer added a commit to ViktorHofer/runtime that referenced this issue May 3, 2023
@ViktorHofer
Remove S.Sec.Crypto.Algorithms package dependency
44cc8d1 
Contributes to dotnet#85641

System.Security.Cryptography.Algorithms/4.3.1 is being referenced in a
few .NET Framework builds. The reference to that package is undesirable
as it brings in the entire netstandard 1.x dependency graph.

The only type used from that package is IncrementalHash which isn't
available as a public API in .NET Framework before 4.7.1. Because of
that, polyfill the netfx code in with minor changes to the source to
make the analyzers happy.
This was referenced May 3, 2023
Merged
Open
ViktorHofer added a commit that referenced this issue May 3, 2023
@ViktorHofer
Remove S.Sec.Crypto.Algorithms package dependency (#85701)
c8f43d5 
* Remove S.Sec.Crypto.Algorithms package dependency

Contributes to #85641

System.Security.Cryptography.Algorithms/4.3.1 is being referenced in a
few .NET Framework builds. The reference to that package is undesirable
as it brings in the entire netstandard 1.x dependency graph.

The only type used from that package is IncrementalHash which isn't
available as a public API in .NET Framework before 4.7.1. Because of
that, polyfill the netfx code in with minor changes to the source to
make the analyzers happy.
@ViktorHofer
Copy link
Member Author

Completed. Closing.

@huoyaoyuan huoyaoyuan mentioned this issue May 24, 2023
Closed
@ghost ghost locked as resolved and limited conversation to collaborators Jun 4, 2023
# for free to subscribe to this conversation on GitHub. Already have an account? #.
Assignees
No one assigned
Labels
area-Infrastructure-libraries
Projects
None yet
Milestone
8.0.0
Development

No branches or pull requests
2 participants
@ViktorHofer @tarekgh