mastodon - Link to source
Hello fedi, any #DotNet and #NuGet experts here please?
I'm trying to prepare a NuGet package where I need to bundle a folder with a DLL and some accompanying files. Everything is good, the nupkg file is created, the folder is there (I can clearly see it with 7-zip). However, when installing the package, the folder is again there in the NuGet global cache, but not in the project where I install it!
I even asked a StackOverflow question [1] about it, but still no dice. Any thoughts please? Thanks!
[1]:stackoverflow.com/questions/78…

External DLLs and other files are in the nupkg and in the global cache, but not installed with the package

I have a .NET 8 library written in C# that uses an external native C DLL, my library is basically a C# wrapper for the C API. I want to make it a NuGet package and use it in my other projects. Here...
Stack Overflow
#dotnet #nuget
in reply to André Polykanine

mastodon - Link to source

Chet Husk

no, you don't need a nuspec. You can do all of this using the Pack and PackagePath metadata like you've done with other package contents.

It's not entirely clear what you mean by 'installed into the project', but you should look inside the project.assets.json in your projects obj folder - this file describes how NuGet sees your package and determines which dependencies will actually end up in your project. If you don't see your native binaries in the project.assets.json...

in reply to Chet Husk

mastodon - Link to source

André Polykanine

@chethusk Sorry, probably I'm not clear. So, step by step:
1. I package my NuGet package using `dotnet pack` and the CsProj you looked at. I'll call this "package".
2. I have another project (I'll call it "app") where I want to *use* the package.
3. I do `dotnet add package` to add the package to the app.
Result? My app does not work because the DLL the package imports is not there at all.
@Chet Husk
in reply to Chet Husk

mastodon - Link to source

Chet Husk

hello again! I found your project on GitHub and I think I can explain what's happening.

The first image is what your package looks like today, with everything copied into the `lib/net8.0` directory. NuGet only automatically references _managed assemblies_ from folders using the `lib/<TFM>` pattern, which is why only your main `SharpLouis.dll` assembly is here.

To fix this, you need to tell NuGet about your _native dependencies_. This can be done with a line similar to what you have.

in reply to Chet Husk

mastodon - Link to source

Chet Husk

Here's the line to make NuGet see your native dependency

```xml
<Content Include="./LibLouis/liblouis.dll" Pack="true" PackagePath="runtimes/win-x64/native" />
```

This is very close to what you already had - the key difference here is the PackagePath - NuGet looks for native dependencies at `runtimes/<RID>/native`, so I've placed the native liblouis at `runtimes/win-x64/native`. When you do this, the package changes - the second image shows NuGet seeing the native deps.

in reply to André Polykanine

mastodon - Link to source

Chet Husk

My apologies! I should have added alt-text to my screenshots, I'll edit to do so now. The remaining information (the tables, etc) I _should_ be able to figure out shortly - NuGet has a `contentFiles` mechanism that I am aware of but haven't used in a while so I'm having to refresh my memory. If you like, I can submit a PR to your PR when I have it all figured out for easier review.
in reply to Chet Husk

mastodon - Link to source

André Polykanine

@chethusk Thank you so much Chet! Now everything is there but I have one more issue: in the SharpLouis code itself I'm trying to import the DLL as if it was in the same LibLouis folder where the tables folder and tables.json are, but it's actually in runtimes/win-x64/native. Is there any way to moving it or should I change the code somehow appropriately? Thank you once more!
@Chet Husk
in reply to André Polykanine

mastodon - Link to source

Chet Husk

what happens if you publish and run your app with 'dotnet publish -r win-x64'? Publishing is what tells the .NET SDK to layout all of your platform specific dependencies for that platform directly next to your app - otherwise you'll need to do a slight amount of work to tell your app how to look in `runtimes/<RID>/...`. I think we have a doc showing this, let me try to find it.
in reply to Chet Husk

mastodon - Link to source

André Polykanine

@chethusk Interesting. If I do just:
<Content Include="LibLouis\**">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<Visible>false</Visible>
<PackageCopyToOutput>true</PackageCopyToOutput>
</Content>
Then I have my DLL where intended, but I started getting random access violation exceptions with message "Attempted to read or write protected memory. This is often an indication that other memory is corrupt." Any thoughts on this also, please?
@Chet Husk
in reply to André Polykanine

mastodon - Link to source

Chet Husk

Sorry for the delay, I spent part of the day talking to some folks inside the .NET org that manage native dependencies like you do. One example I was pointed to was the SkiaSharp library - .NET bindings to the Skia graphics API. Here is some of their logic for making the local-build dev cycle work: github.com/mono/SkiaSharp/blob…

All of the projects in the repo that use the library Import this file: github.com/search?q=repo%3Amon…


SkiaSharp/binding/IncludeNativeAssets.SkiaSharp.targets at main · mono/SkiaSharp

SkiaSharp is a cross-platform 2D graphics API for .NET platforms based on Google's Skia Graphics Library. It provides a comprehensive 2D API that can be used across mobile, server and desktop m...
GitHub
⇧