NuGet package not copied on build/publish, not found on run

I have a simple C# project using two nuget packages that builds and runs fine in VS2017 on Windows set to .NET Core 2.1. If I use dotnet build, dotnet publish or dotnet run in all 3 cases one of the packages is missing from the output directory so it fails to be loaded. dotnet restore doesn’t fix this, neither does setting <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies> in the csproj.

In the csproj you can see the two dependencies here: https://github.com/kg/wasmdis/blob/master/WasmDis.csproj#L36

If you look at the result of a publish, you can see that the native dependencies for Capstone were copied into the output directory but the managed assembly was not. The managed assembly is present in the .deps.json so the dependency is being tracked somehow.

kate@reeir-debian2:~/Projects/WasmDis$ ls -la bin/Debug/netcoreapp2.1/publish
total 768
drwxr-xr-x 5 kate kate   4096 Mar  5 10:02 .
drwxr-xr-x 6 kate kate   4096 Mar  5 10:09 ..
-rwxr--r-- 1 kate kate 693680 Nov  9 00:56 Newtonsoft.Json.dll
drwxr-xr-x 4 kate kate   4096 Mar  5 10:02 runtimes
-rw-r--r-- 1 kate kate    786 Mar  5 09:59 spidermonkey-driver.js
-rw-r--r-- 1 kate kate   2243 Mar  5 10:09 WasmDis.deps.json
-rw-r--r-- 1 kate kate  37888 Mar  5 10:09 WasmDis.dll
-rw-r--r-- 1 kate kate  13196 Mar  5 10:09 WasmDis.pdb
-rw-r--r-- 1 kate kate    146 Mar  5 10:00 WasmDis.runtimeconfig.json
drwxr-xr-x 2 kate kate   4096 Mar  5 10:02 x64
drwxr-xr-x 2 kate kate   4096 Mar  5 10:02 x86
kate@reeir-debian2:~/Projects/WasmDis$ ls -la bin/Debug/netcoreapp2.1/publish/x64
total 3768
drwxr-xr-x 2 kate kate    4096 Mar  5 10:02 .
drwxr-xr-x 5 kate kate    4096 Mar  5 10:02 ..
-rwxr--r-- 1 kate kate 3847680 Jan 11  2019 capstone.dll

kate@reeir-debian2:~/Projects/WasmDis$ dotnet run
Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Gee.External.Capstone, Version=2.0.2.0, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.

It’s not clear to me how to debug this and it’s kind of disappointing that the error feedback/output doesn’t explain that it attempted to load the dependency out of my local package cache (or whatever) and failed.

[filipnavara]

As always, I really recommend NuGet Package Explorer and MSBuild Log viewer as the go-to tools for digging deep into issues like this.

It is really unusual way to package the NuGet. Normally the managed code is shared across RIDs and the native libraries are packaged under different RIDs. Perhaps there’s some good reason for this but it’s not a common setup.

I suppose some warning would be nice but not sure how easy is it to do that (wrt. self-contained vs framework-dependent deployments). There are certain scenarios where the assemblies are intentionally omitted from the implementation because they are supplied by the underlying platform. The whole dotnet SDK itself is composed of NuGets and this is probably the common scenario for the platform itself.

[kg]

OK, so it sounds like the package is authored to do this. Does it really make sense for dotnet build/dotnet publish to ‘succeed’ on a platform and generate an executable that cannot ever possibly work? This feels like a dependency resolution failure that just happens to have been intended by the package author, I would have hoped that some part of the tooling would have noticed it was impossible to resolve the dependency and alert me to it.

Thanks for looking into the metadata, I didn’t know how to do that.