search

erikest / gRPCpi

A gRPC template for dotnet core and the raspberrypi
3 stars 0 forks source link

dotnet cli self-contained publish does not use the native library #1

Open Liriel opened 4 years ago

Liriel commented 4 years ago

Hi erikest! thanks for all the research and for providing the nuget packge. It seems though that adding the package does not automatically copy the correct library when pubilshing.

steps to reproduce:

create a new project and add the packages

dotnet new console -o grpcTest
dotnet add package Grpc.Core
dotnet add package Grpc.Net.Client
dotnet add package Grpc.Tools
dotnet add package libgrpc_csharp_ext.arm7 --version 1.1.0

publish to arm dotnet publish -r linux-arm --self-contained

checking the hashes I get the pc one:

md5sum bin/Debug/netcoreapp3.1/linux-arm/libgrpc_csharp_ext.x86.so
00d9eba5e8ae5fd3da05df17699ce16b  bin/Debug/netcoreapp3.1/linux-arm/libgrpc_csharp_ext.x86.so

should be 46a8d1fe8e97b9578148443c886f41eb (fron the latest nuget package)

any Idea what's goning on?

erikest commented 4 years ago

I don't yet know what the underlying reason is, but I've filed this issue on the CLI github to seek help.

Something appears to have changed in the package selection process between .net core 3.0 preview and 3.1. If you publish verbose, you'll see a line where it has a conflict between the libraries in the linux-arm/ folder and the x86 compiled version in the linux/ folder. These two libraries share a name for reasons I outlined in the article, but it seems that the package selection process is finding both and choosing the the other 'arbitrarily'. The behavior used to be that it would look for a library in the specific rid folder, i.e. linux-arm, and choose that, and then if it did not find the specific rid, fallback to the next available one based on the rid graph (see: [RID graph](https://docs.microsoft.com/en-us/dotnet/core/rid-catalog and linux-arm rid).

So it appears to be a regression in the behavior on the CLI side as there should be no name conflict issue when a specific / exists.

https://github.com/dotnet/sdk/issues/4195

erikest commented 4 years ago

I updated the other issue with better description and your succinct repro steps, thanks!

Liriel commented 4 years ago

it appears the bug made it into the 3.0 release as well (downgrading to 3.0.100 did not change the behavior for me)