Grpc.Net.Common .NETStandard is missing "Grpc.Net.Compression.DeflateCompressionProvider"

[impeham]

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?

https://pasteboard.co/PaeZqwwMYcc5.jpg

[JamesNK]

why is this class missing in the .NETStandard v2.0 version?

Because the types used by DeflateCompressionProvider are only available in .NET 6 or later.

If you're using .NET 6 version of Grpc.Net.Client then you must also use the .NET 6 version of Grpc.Net.Common.

[impeham]

on the debian env we ARE using .net 6 - the same solution is being restored & compiled there We build 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.

in this image, the package that is being restored is the .NETStandard one - i'm not sure why

[JamesNK]

I don't know why. If the wrong version is restored, then it is a NuGet bug.

[impeham]

thanks @JamesNK we'll check that

[maksperovpm]

If we use native nuget from Debian image, we get errors even on install just one package. Example

nuget install Autofac

WARNING: Error: TrustFailure (Authentication failed, see inner exception.)
WARNING: An error occurred while loading packages from 'https://www.nuget.org/api/v2/': Error: TrustFailure (Authentication failed, see inner exception.)

Unable to find package 'Autofac'.

=================================

UPD:

We found alternative that solves our project restore issue. If we restore it with dotnet restore command, it works.

dotnet restore ./PATH_TO_SOLUTION_FILE -s MYGET_REPO -s https://api.nuget.org/v3/index.json

So, the problem is definitely somewhere in NuGet.

[maksperovpm]

Hi,

Problem still persists. We still get exactly the same issue we got with nuget command: Grpc.Net.Compression.DeflateCompressionProvider' from assembly 'Grpc.Net.Common, Version=2.0.0.0

We use this command: dotnet restore ./PATH_TO_SOLUTION_FILE -s MYGET_REPO -s https://api.nuget.org/v3/index.json

as a workaround we overrite Grpc.Net.Common.dll from local machine where Grpc.Net.Common is restored for .NETCoreApp v6.0.

[maksperovpm]

UPD

Now we have another issue for another project with Microsoft.Extensions.DependencyModel.

Summary:

Docker image: mcr.microsoft.com/dotnet/sdk:6.0-bullseye-slim

Command to restore project: dotnet restore ./PATH_TO_SOLUTION_FILE -s MYGET_REPO -s https://api.nuget.org/v3/index.json

Issues:

1. Could not load type 'Grpc.Net.Compression.DeflateCompressionProvider' from assembly 'Grpc.Net.Common, Version=2.0.0.0, Culture=neutral, PublicKeyToken=d754f35622e28bad'
2. Could not load file or assembly 'Microsoft.Extensions.DependencyModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'

While issues are not fixed, workaround is to restore project locally and replace/add dll file from local machine.

[maksperovpm]

We investigated the issue with Microsoft.Extensions.DependencyModel.dll We ran restore command with additional flags --verbosity diagnostic and by the log we should have Microsoft.Extensions.DependencyModel 3.0.0 version, but after publishing project we get Microsoft.Extensions.DependencyModel, Version=2.1.0.0 We checked where in the system we can find this dll file after restore and publish and compared SHAs with that one that we get after publish.

/root/.nuget/packages/coverlet.collector/3.1.2/build/netstandard1.0/Microsoft.Extensions.DependencyModel.dll
/root/.nuget/packages/microsoft.extensions.dependencymodel/3.0.0/lib/net451/Microsoft.Extensions.DependencyModel.dll
/root/.nuget/packages/microsoft.extensions.dependencymodel/3.0.0/lib/netstandard1.3/Microsoft.Extensions.DependencyModel.dll
/root/.nuget/packages/microsoft.extensions.dependencymodel/3.0.0/lib/netstandard1.6/Microsoft.Extensions.DependencyModel.dll
/root/.nuget/packages/microsoft.extensions.dependencymodel/3.0.0/lib/netstandard2.0/Microsoft.Extensions.DependencyModel.dll
/src/src/OM2.Webserver.Host/bin/Release/net6.0/Microsoft.Extensions.DependencyModel.dll
/usr/share/dotnet/sdk/6.0.401/Microsoft.Extensions.DependencyModel.dll
/usr/share/dotnet/sdk/6.0.401/Sdks/Microsoft.NET.Sdk/tools/net472/Microsoft.Extensions.DependencyModel.dll

As a result, this 2 files has the same SHA /root/.nuget/packages/coverlet.collector/3.1.2/build/netstandard1.0/Microsoft.Extensions.DependencyModel.dll and out/Microsoft.Extensions.DependencyModel.dll

We found an issue like ours, here -> https://github.com/dotnet/sdk/issues/3886

We tried one suggested way to fix this by specifying csproj file during publish command RUN dotnet publish ./PATH_TO_CSPROJ_FILE -c Release -o out --no-restore

and IT WORKS

In CSPROJ file case we have sme SHA for this files

/root/.nuget/packages/microsoft.extensions.dependencymodel/3.0.0/lib/netstandard2.0/Microsoft.Extensions.DependencyModel.dll
/src/out/Microsoft.Extensions.DependencyModel.dll
/src/src/OM2.Webserver.Host/bin/Release/net6.0/Microsoft.Extensions.DependencyModel.dll

Seems like when you specify solution file on publish, it can't understand which project is the main one and kinda takes probably the latest project packages versions.

I'll try same solution on other project and will update.

But for now, as summary

SOLUTION: On publish specify csproj file, not sln.