I'm encountering an interesting issue and it could be something I don't know about NuGet currently, but I am creating a NuGet package, which I'll call Project Alpha, that has a dependency on Grpc
, which, in extension, has a dependency on the problematic package: Grpc.Core
.
Grpc.Core
, via Grpc
installs fine in Project Alpha and adds no new files to Project Alpha's project. Project Beta, on the other hand, depends upon Project Alpha, and in extension Grpc.Core
. When I install Project Alpha, the installation of Grpc.Core
causes the following project tree in Project Beta
ProjectBeta
|- Properties/
|- References/
|- App.config
|- grpc_csharp_ext.x64.dll
|- grpc_csharp_ext.x86.dll
|- libgrpc_csharp_ext.x64.dylib
|- libgrpc_csharp_ext.x64.so
|- libgrpc_csharp_ext.x86.dylib
|- libgrpc_csharp_ext.x86.so
|- packages.config
|- Program.cs
You'll notice that it installs 6 binary files that I do not want 1) included in the project or 2) at the project root.
After looking at the Grpc.Core.nupkg
, I found that the 6 binary files came from a runtimes
folder; however, only a .targets
file referenced them and explicitly said to copy to the output directory. It should be noted that it will build correctly by copying those files to the output directory.
For more reference:
Project Alpha Dependency Tree
Project Alpha
|- Grpc
| |- Grpc.Core
|- Google.Protobuf
results in the following nupkg after running nuget pack ProjectAlpha.csproj -Properties Configuration=Release
content
|- grpc_csharp_ext.x64.dll
|- grpc_csharp_ext.x86.dll
|- libgrpc_csharp_ext.x64.dylib
|- libgrpc_csharp_ext.x64.so
|- libgrpc_csharp_ext.x86.dylib
|- libgrpc_csharp_ext.x86.so
lib
|- net452
|- ProjectAlpha.dll
Ultimately, it seems like I need to figure out what to do with those binary files so that they no longer get packaged as content
files, but I am not sure what is causing this problem in the first place. Ideally, I'd like to have a solution that isn't just "Why don't you just delete the files since it builds?". If that ends up being the only solution, then I will do that; however, I don't think that is a real solution.
Any ideas? Suggestions? Hacks?
I found a solution to this problem. I had attempted to use .nuspec
and exclude the binaries, but that did not work and I actually received problems just installing the NuGet package.
The best approach I found (because it works for me) is to use the command-line arguments for nuget pack
that I missed before, which is -Exclude
.
So the final command I used to package up the .csproj
is
nuget pack ProjectAlpha.csproj -Exclude **\*.x86.*;**\*.x64.*
In case the solution is not clear, nuget pack
will package up everything found in the output directory (bin\Debug
or bin\Release
) and the problem was arising because there were 6 binaries for which NuGet didn't know the origin. I know they were copied via the .targets
file in Grpc.Core
's NuGet package. So, they needed to be excluded because the .targets
file would copy them correctly in any subsequent project that would include Grpc.Core
. Thus, -Exclude
worked.
I still do not know why it worked better in this case than a .nuspec
exclude attribute, but I'm happy that it's solved!
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With