runtime: Grpc.Net.Common .NETStandard is missing "Grpc.Net.Compression.DeflateCompressionProvider"
Description
I’m using a host application which targets .NET 6.0 with GRPC service developed under windows which references “Grpc.Net.Common”. under windows all works great but when the solution is built and packages restore under a debian machine (docker), it restores this library as .NETStandard v2.0 which is not the same one which is restored on my machine (mine is .NETCoreApp v6.0). when i started the service under debian i got the following exception:
---> System.TypeLoadException: Could not load type 'Grpc.Net.Compression.DeflateCompressionProvider' from assembly 'Grpc.Net.Common, Version=2.0.0.0, Culture=neutral, PublicKeyToken=d754f35622e28bad'.
when i opened the Grpc.Net.Common under dotPeek from the docker (.NETStandard v2.0) i can see that Grpc.Net.Compression.DeflateCompressionProvider doesn’t exist there. it DOES exist on the .NETCoreApp v6.0 version which was restored on my windows machine. why is this class missing in the .NETStandard v2.0 version?
in this image, the package that is being restored is the .NETStandard one - i’m not sure why https://pasteboard.co/PaeZqwwMYcc5.jpg
On the debian env we ARE using .NET 6 - the same solution is being restored & compiled there We restore our project based on mcr.microsoft.com/dotnet/sdk:6.0-bullseye-slim docker container, with this command:
RUN nuget restore ./PATH_TO_SOLUTION_FILE
the “nuget” package we are using was installed from Mono repository because the native nuget from debian 11 was causing us issues.
Reproduction Steps
In this image mcr.microsoft.com/dotnet/sdk:6.0-bullseye-slim install cross-platform NuGet from Mono-Project repository and try to restore a project that uses package <PackageReference Include="Grpc.Net.Common" Version="2.41.0" />
Expected behavior
Restore .NET 6 version of Grpc.Net.Common.
Actual behavior
Restore .NETStandard v2.0 version of Grpc.Net.Common.
Regression?
No response
Known Workarounds
No response
Configuration
No response
Other information
No response
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 17 (11 by maintainers)
Both this and the linked issue are about publishing providing an output path. I clarified the comment above. I don’t think there should be a problem publishing a sln without an output path. The problem when specifying an output path is that gets used as a global property to every project in the SLN and their outputs will clash with each other, overwriting files at random.
If you are facing any problem, please open a new issue to report. Thanks!
Yes. Grpc.Net.Common and Grpc.Net.Client have multiple targets. The .NET Standard 2.0 target doesn’t have
DeflateCompressionProvider. For some reason the netstandard2.0Grpc.Net.Commonis being restored with net6.0Grpc.Net.Client.There is no reason to open a bug in grpc-dotnet because this isn’t a bug in grpc-dotnet. Something is wrong with how NuGet is restoring assemblies. And a custom copy of NuGet is being used which seems like a red flag.