Improve documentation on creating native packages

[nuget]

Improve documentation on creating native packages

[ericstj]

Just hit this myself when trying to tell folks to use nativeassets. Can we please get docs for this feature that's been around for 2 years now? /cc @jainaashish @rrelyea

[Mizux]

my 2 cents for "Building a cross-platform .NetStandard2.0 package with native dependencies" (only using dotnet/cli and modern .csproj)

I add my own way to do it there #1013 (comment)
And you can found a full example project in https://github.com/Mizux/dotnet-native (Documentation on the way)

Still, waiting for the official documentation !!!

[jjpepper]

@kraigb that's not really correct. We don't really need anything vcpkg specific here, someone might be building in linux and producing a shared libraries from there without vcpkg being in the picture at all. The C++ people will know how to build their own libraries. The bigger question is then how to structure/create a nuget package via .nuspec so that the native libraries wind up in the target directory of the C# application that references the package. That expertise should exist within the nuget team, as it's just nuget functionality. Our approach was to use a .targets file, with the unfortunate side effect that the C# project that uses the native package sees all the shared libraries along side the source files in the solution explorer view. Yuck!

[Mizux]

@jjpepper why do you use/hack a target file instead of setting it in the .*proj file ?
And did you try the <Visible> property (which should work in .*proj) ?
src: https://docs.microsoft.com/en-us/visualstudio/msbuild/common-msbuild-project-items?view=vs-2017#content

[Mizux]

FYI I've updated https://github.com/Mizux/dotnet-native to add "real" C++ samples code up to the .Net wrapper generation (using SWIG to generate the .NET wrapper from the C++ code) and I've updated my documentation accordingly.

There is also github actions workflows CI and few Linux docker to test on various distros as well as tests using MacOS and Windows runners.

[kraigb]

See also https://github.com/MicrosoftDocs/mvp-hackadoc-2018/issues/43

[ras0219-msft]

no way to create a standalone package for publishing on the official repository :-(.

Take a look at our export command [1][2].

[1] https://blogs.msdn.microsoft.com/vcblog/2017/05/03/vcpkg-introducing-export-command/
[2] https://github.com/Microsoft/vcpkg/blob/d80dd5cbc777ce765c2d6b78d7c485fdf05f284b/docs/users/integration.md#export

[kraigb]

What we really need is someone familiar with the process using vcpkg to draft a walkthrough that demonstrates the whole process of creating a native package. That expertise unfortunately does not seem to exist within the NuGet team. I can provide editing help and bringing the draft up to docs quality. Just create a branch with the work in it and we can go from there.

[kraigb]

Also addres #190, #592, and #600.

[jjpepper]

Does anyone know if there is a way of making native libraries specified in a targets file not appear in the solution view?

[stale]

This issue has been automatically marked as stale and closed because it has not had recent activity. Thank you for your contributions.

[Mizux]

still not resolved officially...

[tebeco]

I'm really curious about a dotnet pack solution when vendor just gives you MyNative.dll and MyDotnetWapper.dll, refusing to create nupkg.

That's also a VERY common scenario for "legacy" nuget or third part that was used thx to <Reference and truing to move forward to <PackageReference by manually repackaging already built dll.
They are supposed to be repackaged to netstandard2.0 since some could target net47x for example.

As of today i never found a clear and clean solution :(

[karann-msft]

Not eligible for docs day.

[tebeco]

hello @karann-msft
would something like this helps as a support for documentation ?
NuGet/Home#9502

This repository show a "way" that vendor uses (that is bad ... as they gives us RAW .net dll)
https://github.com/tebeco/NativeLibNugetStuff/blob/master/README.md

The original repo from @poke, shows a better way => properly packing the native + managed, it only depends on what you have on your hands
https://github.com/poke/NativeLibNugetStuff

I think both could be a good contribution to the the docs as it would helps vendor to have something to rely on, in order to release fully functional packages compliant with dotnet restore and dotnet publish

[github-actions]

Thanks for sharing your feedback. We apologize for our delayed response. Due to the sheer volume of feedback in our repo, we have decided to prioritize the newest issues and are automatically closing our oldest issues with an Issues bot. If you believe your feedback is still actionable, then either respond directly in this issue or open a new documentation issue and we’ll review. If no activity occurs in the next 14 days, this issue will be closed.