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 #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.

[0xced]

I also stumbled on this today. I went down the rabbit hole, tried to add an MSBuild target in my unit tests project to make the GenerateDepsFile task (wich is responsible for producing the *.deps.json file) add the required runtimeTargets but no dice! It is impossible to have the GenerateDepsFile to include the runtimeTargets node for a project reference, it only works with (NuGet) package references! (Yes, I had fun debugging the GenerateDepsFile task with MSBuildStructuredLog's TaskRuner. See, the rabbit hole is deep.)

What works though is having the native library in the same directory as the assembly performing the P/Invoke. (Yes, I built a debug version of the CoreCLR and set breakpoints with lldb to figure this out while it would have been pretty easy to just try having both the managed assembly and native library in the same directory! See, deep is not enough to describe the rabbit hole.)

So, after all these hours spent figuring this out, the easiest workaround I found is to instruct MSBuild to copy the native libraries into the output directory of the unit tests project:

<ItemGroup>
  <None Include="..\runtimes\linux\native\*" CopyToOutputDirectory="PreserveNewest" Condition="$([MSBuild]::IsOSPlatform('Linux'))" />
  <None Include="..\runtimes\osx\native\*" CopyToOutputDirectory="PreserveNewest" Condition="$([MSBuild]::IsOSPlatform('OSX'))" />
  <None Include="..\runtimes\win\native\*" CopyToOutputDirectory="PreserveNewest" Condition="$([MSBuild]::IsOSPlatform('Windows'))" />
</ItemGroup>

Like others have already said in this issue, handling of project references and package references should not diverge as much regarding native libraries. I really hope to see this addressed in a future version of the SDK.