Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Binaries are added to project when NuGet package has Grpc.Core as a dependency

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?

like image 857
tuxagon91 Avatar asked Jan 30 '17 17:01

tuxagon91


1 Answers

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!

like image 68
tuxagon91 Avatar answered Oct 11 '22 09:10

tuxagon91