dotnet/sdk

Copy runtime libraries from references project

oryol opened this issue · 13 comments

oryol commented

I have Library.csproj with following code:

<ItemGroup>
    <Content Include="runtimes\win7-x86\native\**\*">
      <PackagePath>.</PackagePath>
      <Pack>true</Pack>
    </Content>
</ItemGroup>

When I run dotnet pack, I can see native dll-s in the generated package.
If I reference this NuGet package (using my own feed) in the another project then all libraries are correctly placed into bin folder. But if I reference this project directly then libraries are not copied.

We need to have one uniform way to add native libraries into project and use them in all scenarios:

  • Directly in this project
  • In other project that references this project
  • In the generated NuGet package
livarcocc commented

@oryol I just tried this as your described. And while I see the dlls under runtimes/win7-x86/native show app at the root of the package, as indicated by the PackagePath, I don't see them being copied in the output of applications that reference this package.

Did you do anything different from what is described here to achieve that?

  • 👍1
livarcocc commented

The way that I managed to get this to show up during a publish of a dependent up was to do this in the lib before packaging it:

<PackagePath>lib\$(TargetFramework)</PackagePath>
livarcocc commented

We need a NuGet fix before continuing this. I chatted with @dsplaisted and his suggestion is that NuGet should generate the assets.json reference to project B in a similar manner for both ProjectReference and PackageReference. Once NuGet does that, the SDK can use that information to move the files.

dsplaisted commented

@natidea @rrelyea @srivatsn @emgarten For this to work, I think we would want NuGet restore to write information about Content items with Pack=true to the assets file. Does that sound right?

emgarten commented

@dsplaisted we need restore to find all assets that would be packed for each project, restore could then determine which assets are used and write those to the assets file. Build would then need to use only these assets for the project, the same as if it were a package.

I've added more details on this in the NuGet issue tracking this.

rrelyea commented

What is the timeframe you guys are hoping to fix this? (don't see one).
In the linked nuget issue, we explain that we believe this kind of change is out of scope for rtm.
wanted to confirm that the work needed here can come later.

srivatsn commented

Given the scope of change this is post RTM.

rwasef1830 commented

Any csproj hacks or workarounds for this in the short term ? This is very painful for unit test projects that are trying to test a library that has a native dependency.

  • 👍1
dabretin commented

So ???

Apollo3zehn commented

Is there any plan to solve this eventually? How can we have unit tests referencing a project which depends on native assemblies?

  • I don't like the solution to create a separate package containing only the native libs and then referencing this package since then one has to publish them one after another, which makes CI difficult.
  • In the unit test project I tried to create a PackageReference instead of a ProjectReference. With the package reference I can point to the locally generated .nupkg. But this only works once since the second time this package is resolved from the %userprofile%/.nuget/packages cache...

Similar issues:

#1088
https://github.com/dotnet/cli/issues/7500
NuGet/Home#4514

asmichi commented

I have made an extreme hack to add runtime libraries into deps.json: https://github.com/asmichi/DotNetInjectNativeFileDepsHack
WARNING: This will likely break in a future version of the .NET SDK.

The problem is that runtime libraries from reference projects do not appear in deps.json and thus cannot be loaded by DllImport. Only NuGet libraries can have runtimeTargets! Okay, then, trick the build to add runtime libraries into an existing NuGet library.

  • 👍3
silkfire commented

Another thing that doesn't seem to be possible at the moment is specifying a subdirectory where the native library ends up after publish. Right now they're all emitted to the root (/publish/) directory, regardless if they reside in a subdirectory inside the NuGet package itself (/runtimes/<arch>/native/sub1/sub2/mylib.dll).

  • 👍1
michaelosthege commented

Crossref #17527 appears to be a newer ticket specifically about lacking the runtimes folder when building for cross-platform.