Runtime native dll not copied beetween local projects

Steps to reproduce

On the SharpScss repo, I have a SharpScss assembly project that is shipping runtime native libraries and this project is referenced from a SharpScss.Tests xunit tests.

(related issue in SharpScss#6)

When running dotnet test from the src folder, I’m getting DllNotFoundException as It seems not able to resolve the libsass native dlls/so.

When consuming the NuGet package SharpScss, the runtime/native dlls are properly resolved.

In the generated SharpScss.Tests.deps.json, we can see that the runtime native dlls are not listed:

      "SharpScss/1.3.8": {
        "runtime": {
          "SharpScss.dll": {}
        }

while using the NuGet package, they are correctly setup:

      "SharpScss/1.3.8": {
        "runtime": {
          "lib/netstandard1.3/SharpScss.dll": {}
        },
        "runtimeTargets": {
          "runtimes/linux-x64/native/libsass.so": {
            "rid": "linux-x64",
            "assetType": "native"
          },
          "runtimes/osx-x64/native/libsass.dylib": {
            "rid": "osx-x64",
            "assetType": "native"
          },
          "runtimes/win-x64/native/libsass.dll": {
            "rid": "win-x64",
            "assetType": "native"
          },
          "runtimes/win-x86/native/libsass.dll": {
            "rid": "win-x86",
            "assetType": "native"
          }
        }
      },

Expected behavior

When referencing a local project that has runtime native dlls, they should be part of the dependencies when trying to use them from another project.

Actual behavior

Native dlls are not referenced as described above.

Environment data

dotnet --info output:

.NET Command Line Tools (2.0.0)

Product Information:
 Version:            2.0.0
 Commit SHA-1 hash:  cdcd1928c9

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.15063
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.0.0\

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0
  Build    : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d

I’m not sure if this issue belongs to here or to the dotnet/project-system (cc @davkean)

[dasMulli]

It would be great to have sth like a @(RuntimeAsset) item that is copied to the right path in outputs and packed correctly… (and e.g. respects the inferred RID for netfx projects etc)

<ItemGroup>
  <RuntimeAsset Include="cool.dylib" RuntimeIdentifier="osx-x64" />
  <RuntimeAsset Include="libcool.so" RuntimeIdentifier="linux-x64" />
  …
</ItemGroup>

[xoofx]

It gives quite an unbalanced experience. Importing a project should provide what would be imported by the nuget package itself. We should not have to deal with these differences.

Solving this in the tests project is cumbersome, as you basically need to detect which platform you are running, add an explicit references to the native dlls (while the test project should not be aware of it). You can create a shared .targets file, that’s what we had to do in the past on Windows… but that’s really super annoying to have do this, specially in the new .NET Core xplat story which complicates a lot the build.

We should have a parity experience here. Otherwise, it means that whenever you have native dlls, you can’t easily develop cross platform tests and we are forced do develop special build steps to overcome this.

So @wli3, you suggest that this issue could be moved the project-system then? (if yes, @karelz or @davkean could you move the issue?)