grpc: Transitive dependencies are broken in Grpc C# (new-style csproj projects targeting net45+)
Something about the packaging of gRPC - in particular the native component - looks like it’s changed in 1.3.0, which causes the native library to not be found.
Sample csproj:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net452</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Grpc.Auth" Version="1.3.0" />
</ItemGroup>
</Project>
And program:
public class Program
{
static void Main()
{
// Just force the native methods to get loaded
var server = new Grpc.Core.Server();
}
}
(It doesn’t get much more minimal than that 😃
Run dotnet restore
then dotnet run
, and you’ll get an exception with a failure to find the native DLL. The exception isn’t important - but the fact that the native DLL isn’t under bin\Debug\net452
is.
Now, this can be fixed by either of:
- Adding a direct package dependency to
Grpc.Core
version 1.3.0 - Changing
Grpc.Auth
to version 1.2.0.
Presumably there’s some change in the packaging (I suspect of Grpc.Core) between 1.2.0 and 1.3.0 that makes this indirect dependency break.
I’d urge this to be treated as a high-priority bug.
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 23 (15 by maintainers)
Verified - basically this can be propagated using
<PrivateAssets>None</PrivateAssets>
in the whole chain betweenGrpc.Core
and the final application, but that’s really fragile.@onovotny: Is this something you know about? Is there a better way of packaging native binaries these days?
https://github.com/NuGet/Home/issues/4521 seems to suggest adding for the dependency
<PrivateAssets>None</PrivateAssets>
should fix this?The annoying thing is that while we can fix this for Grpc.Auth (and other packages we own), if someone creates a nuget package that depends on Grpc.Core and uses dotnet SDK for that, she’ll need to use the same trick.