Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

SNI package does not respect RuntimeIdentifier property #2671

Open
julealgon opened this issue Jul 12, 2024 · 1 comment
Open

SNI package does not respect RuntimeIdentifier property #2671

julealgon opened this issue Jul 12, 2024 · 1 comment

Comments

@julealgon
Copy link

Describe the bug

When assigning a specific RuntimeIdentifier during publish, NuGet packages are supposed to only copy the required DLLs for the affected platforms/runtimes.

For example, if I specify win-x64 as the RID, I should not expect to see x86 and arm versions of DLLs in the output.

However, the Microsoft.Data.SqlClient.SNI package does not respect that, and always copies all of the native versions to the target output folder, namely:

  • Microsoft.Data.SqlClient.SNI.x86.dll
  • Microsoft.Data.SqlClient.SNI.x64.dll
  • Microsoft.Data.SqlClient.SNI.arm64.dll

This creates unnecessary clutter in my applications, increasing the deployment package size.

To reproduce

  1. Create a brand new console application.
  2. Add a dependency to either Microsoft.Data.SqlClient or Microsoft.Data.SqlClient.SNI packages.
  3. publish the project using RID win-x64
  4. Observe x86 and amd64 native dependencies in the output

Expected behavior

Only the DLLs that match the runtime/architecture of the project should be present in the output if the setting is explicitly defined. It should only contain all possibilities if publishing without any specific architecture in mind.

Further technical details

N/A

Additional context
I believe this issue exists because the package does not declare its native dependencies using the proper RID folder structure, and instead follows what seems to be a completely custom approach to copying the native dependencies.

It looks to me that moving to the intended runtime folder with the runtime identifiers inside would be the way to go. Here is another dependency we use that uses that format:

image
https://www.nuget.org/packages/Grpc.Core

@JRahnama
Copy link
Member

@julealgon thank you for bringing this up. We will take a closer look to SNI.targets file and will get back to you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Needs Investigation
Development

No branches or pull requests

2 participants