libgit2/libgit2sharp — pull request #772 by ethomson (2014-06-23 14:58:23+00:00)
Title: WIP: Move NativeBinaries to a NuGet package

I poked around this weekend on moving the NativeBinaries to a NuGet package and had some limited success. This is definitely not ready for prime-time, but I think we're moving in the right direction.

My thinking here is that there will be two NuGet packages - one for LibGit2Sharp, one for LibGit2. The LibGit2Sharp NuGet package will depend on the LibGit2 package. The LibGit2Sharp project itself, for the developers, will depend only on the LibGit2 package.

This spike shows how this might be possible, but there are many disappointing aspects at the moment:

- [ ] NuGet package restore does not appear to re-run the `install.ps1` script. So the checked-in versions of the `LibGit2Sharp.Tests.csproj` have the post-build copy stuff added to them. I had a bit of a hope that people without NuGet might be able to build successfully (and then provide their own NativeBinaries) instead of having the build fail for them. Maybe a `.targets` will satisfy this, the whole `.targets` thing is still a mystery to me.
- [ ] NuGet packages seem to want to include every DLL as a project reference unless you explicitly list them. (For example, the current LibGit2Sharp NuGet package includes the LibGit2Sharp.dll and the native dlls, and explicitly lists the reference assembly as LibGit2Sharp.dll. As a result, NuGet does not try to add project references for the native libraries.) However, an empty `` section is treated as if you did not include *any* references, so it tries to add references to the native libraries, which of course fails. Thus I have included a `LibGit2Sharp.Dummy.dll`. I don't yet know how to get around this. Maybe using a CoApp package? Ugh.

Anyway. This still needs a lot of work to get it into a mergeable state, unfortunately. But I wanted to push this up in case somebody else was able to assist.