Include nuget.config for custom native nupkg

[ethomson]

Allow consumers to include a custom nuget package inside the LibGit2Sharp repository (Lib/NativeBinaries), which may be useful for people who fork this repository and want to use a custom libgit2, but one that is not generally available on some Nuget server.

This is something that we do in our workflow with the new-style LibGit2Sharp.NativeBinaries package. While checking this file into this repo isn't strictly necessary, it would help us avoid recreating this each time.

[nulltoken]

While checking this file into this repo isn't strictly necessary, it would help us avoid recreating this each time.

I'm not sure about checking this in. It looks a little bit invasive. How about rather providing some guidance in the readme?

This is something that we do in our workflow with the new-style LibGit2Sharp.NativeBinaries package

Considering this, do we still need the setting introduced in #992? /cc @carlosmn @Therzok

[nulltoken]

@Therzok @carlosmn Any idea why Travis cringes on the NuGet packages restoration?

[shiftkey]

@nulltoken perhaps it needs some activePackageSource to be defined?

https://github.com/github/VisualStudio/blob/master/nuget.config#L7-L9

[ethomson]

While checking this file into this repo isn't strictly necessary, it would help us avoid recreating this each time.
I'm not sure about checking this in. It looks a little bit invasive. How about rather providing some guidance in the readme?

I don't think that there's any point in that, it's very well documented in the nuget docs. This isn't about discoverability as much as convenience and stability: the less we diverge from the upstream LibGit2Sharp, the easier it is for us.

Considering this, do we still need the setting introduced in #992?

Yes. These concerns are related: we need to be able to produce a custom LibGit2Sharp.NativeBinaries nuget package with custom names and then have our LibGit2Sharp load it. We want to check this in to our LibGit2Sharp repository because we don't have a nuget server that everybody that we distribute our package can all access.

Indeed we could check in the nuget.package at the same time but this solution should (note: should) be both flexible and generic enough that it's generally useful and not harmful to the normal use case.

I say should though:

Any idea why Travis cringes on the NuGet packages restoration?

Only the Mac travis build, strangely. packageSources in a nuget.config should append to the package source list, not overwrite it. AFAIK there isn't any reason that this should affect nuget's ability to load packages from the normal sources. Puzzling.