Build NuGet v3/dotnet cli compatible package

[ah-]

The new NuGet v3/dotnet cli tooling now has built-in support for distributing native binaries. It will automatically load relevant libraries without the need to do anything special, it's not even necessary anymore to have a build task to copy them around, everything just works.

This is used for example by the https://www.nuget.org/packages/Libuv/ package for Kestrel.

Making use of this is trivial: Just place the libraries in a special folder structure and NuGet automatically picks them up.

Currently, the binaries live here:

libgit2/linux/x86_64/libgit2-381caf5.so  
libgit2/osx/libgit2-381caf5.dylib  
libgit2/win32/x64/git2-381caf5.dll  
libgit2/win32/x86/git2-381caf5.dll  

All that needs to be done is to move them here:

runtimes/linux-x64/native/libgit2-381caf5.so
runtimes/osx/native/libgit2-381caf5.dylib
runtimes/win7-x64/native/git2-381caf5.dll
runtimes/win7-x86/native/git2-381caf5.dll

I tried to create a PR but couldn't quite figure out how all the build scripts etc. work and it seems hard to test without direct access to the build servers.

Therefore I repackaged the existing LibGit2Sharp.NativeBinaries package with the new folder structure: https://www.nuget.org/packages/LibGit2Sharp.NativeBinaries-dotnet/ as an example. I tested that package and it works nicely.

Do you think you could update the build scripts to output nuget v3 compatible packages? Should just be a matter of adjusting the paths and then updating the old-school build.props so existing users don't break.

Let me know if you need a hand, happy to help out.

[ethomson]

Interesting. This seems reasonable - do you know where the documentation for this lives? I poked around in https://github.com/NuGet/NuGet.Client but didn't see anything obvious.

[bording]

do you know where the documentation for this lives?

From what I've seen, it's not documented well at all yet. There is this, but that is very focused on UWP. How it actually works outside of UWP seems to be a bit of a mystery at the moment.

The lack of documentation is one of the reasons I hadn't tried to propose this myself yet. What sort of changes would be needed on the main library side to take advantage of the loading when using CoreCLR? Not sure yet.

[ah-]

Yes, there isn't very much documentation besides the UWP one linked above. I've mostly gone and looked at what Kestrel and the rest of the new asp.net core projects are doing.

This is a feature of nuget v3, so everything using nuget v3 can benefit from it, including dotnet cli, UWP and csproj projects with project.json for nuget (see https://github.com/NuGet/Home/wiki/Converting-a-csproj-from-package.config-to-project.json).

For the library side there is nothing to do, the library name in the P/Invoke declaration is enough. In dotnet cli based projects it adds $HOME/.nuget/libgit2sharp.nativebinaries/runtimes/$TFM/native/ to the dll search path, when building otherwise it knows your current runtime (e.g. win7-x64) and then copies the relevant dll into your output directory.

[ethomson]

Hrm. The reason I ask for docs is - why win7? Does that mean "windows 7 and better", I assume? We support Vista and better, should this really be win7 or something else?

[ah-]

Yes it does mean windows 7 and better. There's some documentation on that here: https://docs.microsoft.com/en-us/dotnet/articles/core/rid-catalog

[carlosmn]

If these are nuget v3 features, does that mean people who want to download and install the library need to use v3 as well? We wouldn't be able to rely on that being the case for quite some time.

[ah-]

For people on nuget v2 not much changes at all. The files are just in a slightly different place, but there's still the build.props that copies them to the output folder. It just completely ignores the v3 features and the old way keeps working.

[damageboy]

Just to make sure I understand how this works:

• existing .csproj files continue to use the build.props / .targets path
• New dot-net-core projects, that target a specific dot-net-core runtime that target a specific runtime in their project.json get the right binary deployed at build time accordting to their runtime (RID)
• New dot-net-core projects, when they target the existing .net framework... what exactly happens? Do they also get the correct version deployed according to their runtime (RID)?