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

[maksperovpm]

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

[dotnet-issue-labeler[bot]]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[danmoseley]

@JamesNK can you help route?

[JamesNK]

It sounds like a NuGet problem. This bit seems suspicious:

the "nuget" package we are using was installed from Mono repository because the native nuget from debian 11 was causing us issues.

[danmoseley]

@JamesNK it seems DeflateCompressionProvider is 6.0 and later:

https://github.com/grpc/grpc-dotnet/blob/884d918e3c136d18eada731f89babe1dd3a976aa/src/Grpc.Net.Common/Compression/DeflateCompressionProvider.cs#L19

Does it compile successfully against .NET Standard 2.0?

[danmoseley]

BTW, I guess this issue should be reopened in https://github.com/grpc/grpc-dotnet ?

[JamesNK]

@JamesNK it seems DeflateCompressionProvider is 6.0 and later:

grpc/grpc-dotnet@884d918/src/Grpc.Net.Common/Compression/DeflateCompressionProvider.cs#L19

Does it compile successfully against .NET Standard 2.0?

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.0 Grpc.Net.Common is being restored with net6.0 Grpc.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.

[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'.

[ghost]

Tagging subscribers to this area: @dotnet/area-meta See info in area-owners.md if you want to be subscribed.

Issue Details

---

### 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 `` ### 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_

Author:	maksperovpm
Assignees:	-
Labels:	`area-Meta`, `untriaged`
Milestone:	-

[maksperovpm]

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.

[ghost]

This issue has been marked needs-author-action and may be missing some important information.

[ericstj]

Do you happen to be using Packages.config or raw binary references? My best guess here is that your application project doesn't have a package reference to these assemblies, which often happens when the build is unable to calculate the project/package graph. This can happen when a project has a binary reference, or a project reference to a project using packages.config (which behaves like a binary reference). These are just guesses, of course, but they might help you spot the problem.

What would be best to help you would be to share a repro of your issue and we can examine that. If you can't share a repro, a binary log might be enough.

[maksperovpm]

Thanks @ericstj

Your hint led us to check some things.

We start investigating the issue with Microsoft.Extensions.DependencyModel.dll We run 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.

[ericstj]

I'm glad you were able to solve it! Publishing a SLN specifying an output directory is a pitfall that should be prevented. This issue is tracking preventing that: https://github.com/dotnet/sdk/issues/15607

[nagilson]

Publishing a SLN is a pitfall that should be prevented

The specific issue linked is related to providing -o when publishing a solution. Did you mean that dotnet publish on a solution shouldn't be allowed at all @ericstj ?

[ericstj]

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!