Closed maksperovpm closed 1 year ago
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.
@JamesNK can you help route?
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.
@JamesNK it seems DeflateCompressionProvider is 6.0 and later:
Does it compile successfully against .NET Standard 2.0?
BTW, I guess this issue should be reopened in https://github.com/grpc/grpc-dotnet ?
@JamesNK it seems DeflateCompressionProvider is 6.0 and later:
grpc/grpc-dotnet@
884d918
/src/Grpc.Net.Common/Compression/DeflateCompressionProvider.cs#L19Does 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.
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'.
Tagging subscribers to this area: @dotnet/area-meta See info in area-owners.md if you want to be subscribed.
Author: | maksperovpm |
---|---|
Assignees: | - |
Labels: | `area-Meta`, `untriaged` |
Milestone: | - |
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.
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.
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.
This issue has been marked needs-author-action
and may be missing some important information.
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.
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.
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
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 ?
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!
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