Sdk: Runtime native dll not copied beetween local projects

[xoofx]

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)

[wli3]

Hi @xoofx thank you for the issue.

From my understanding. test is referencing _SharpScss_ which contains _libsass_ dlls as artifact. And it is using DllImport to import the artifacts.

sdk does not have built in support dll referencing, so it is suggested to use nuget to fetch libsass.

If you want to keep existing approach, you need to make sure the libsass are copied to _SharpScss_ output. The test can reference the libsass in correct directory.

There are a lot of custom build in the repo. I don't think this is a bug in SDK, I will close it for now.

[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?)

[davidfowl]

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.

Agreed 👍 . I believe this is an explicit goal. Native assemblies were discussed in the past when we were discussing project package parity but were not implemented.

/cc @nguerrera

[nguerrera]

Yes. We can keep this open and on the backlog. Probably should be tracked on dotnet/sdk but with the forthcoming repo merge, it would just come back here so I'll leave it here. There might also be project system implications but we'd need to get command line build working first. To set expectations, this is a big work item that would probably only land in a major release.

[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>

[wli3]

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.

That is true if the dlls are consumed by nuget. However, for this specific project, the following msbuild script diverged the nuget case and p2p case explicitly. And I think there is some thing wrong importing SharpScss.targets causing dlls are not copied to output folder, since SharpScss.targets has logic to copy the dlls

https://github.com/xoofx/SharpScss/blob/master/src/SharpScss/SharpScss.csproj#L46

  <ItemGroup>
    <Content Include="runtimes\**\*">
      <PackagePath>%(Identity)</PackagePath>
      <Pack>true</Pack>
    </Content>
    <Content Include="build\SharpScss.targets">
      <PackagePath>build/net20/SharpScss.targets</PackagePath>
      <Pack>true</Pack>
    </Content>
    <Content Include="build\SharpScss.targets">
      <PackagePath>build/net35/SharpScss.targets</PackagePath>
      <Pack>true</Pack>
    </Content>
    <Content Include="build\SharpScss.targets">
      <PackagePath>build/net40/SharpScss.targets</PackagePath>
      <Pack>true</Pack>
    </Content>
  </ItemGroup>

[xoofx]

This file is to allow to use the NuGet package on a legacy .NET Full framework (via old package.config) It is not used for a .NET Core project. It is just an extra legacy support (or use it even on Mono on a Linux or MacOsX platform)

[wli3]

https://github.com/dotnet/cli/issues/7468

[xoofx]

It is unclear from dotnet/sdk#8627 but it looks like it is requesting for the ability to add a reference to a path dll directly from the CLI and not to support native dll with multiple xplat versions in the build system...

[Ghasan]

This was the last thing I would have expected. Like the docs should mention that runtimes won't be copied unless the package is already packaged into a nupkg and referenced as so (nupkg) not a project reference. But even so, why is it like this in the first place it is confusing.

[nxrighthere]

I've encountered the same problem recently but with the publish command. Runtime native libraries are not copied between local projects, so this requires to explicitly reference NuGet packages of the "parent" project to get a proper self-contained library.