Runtime native dll not copied beetween local projects
See original GitHub issueSteps 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)
Issue Analytics
- State:
- Created 6 years ago
- Reactions:9
- Comments:12 (6 by maintainers)
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)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?)