LocalDebug configuration using locally-built libgit2

[jeffhostetler]

Here is an alternative to #1193. Much simpler.

The goal is to allow you to use a locally-built version of libgit2.dll rather than getting it from the
NativeBinaries NuGet package. This allows you hack on libgit2 and immediately use/test it
from C# without needing to build/deploy your own local NuGet package.

It works by defining a new "LocalDebug" configuration (based upon the standard "Debug"
configuration). We then can switch the value of Core.NativeDllName.Name at compile time
using conditionals in the .csproj. It also allows you to quickly switch between "Debug" and
"LocalDebug" in VisualStudio to do A/B testing on libgit2.

As a convenience, I also let you set "LIBGIT2_LOCALDEBUG" environment variable to
point to the directory containing your local build. This value is prepended to your PATH.
This step is optional.

[Therzok]

What I was thinking is doing /p:NativeFileName="Path\To\NativeFileName.cs" and including that file from the property or defaulting to whatever it is.

Or modifying the task which generates that file to be superseded by this property.

[jeffhostetler]

I suppose there are several ways to do this.

Doing /p:NativeFileName... is one I hadn't considered. But then to use it, everyone would
need to create a personal NativeFileName.cs file that has the proper string variable defined.
Seems like a little extra work. And perhaps hard for devs to discover. But then it would let them
set a full path. Passing this option on the command line is simple enough, but how would one
expose that from Visual Studio? Changing from "Debug" to "LocalDebug" is a first class operation
and understood by users.

WRT updating the generate task, I looked at that, but without a good way to indicate that
NativeDllName.cs (the source itself) depends upon some /p flag, it was too easy to confuse
the build and use a stale .cs file. (There's probably a way, but I didn't dig far enough.)

[bording]

After catching up on the comments on #1193, I think I see a pretty easy way to let LibGit2Sharp load a locally built version that wouldn't require any code changes, and would allow for a quick code -> build -> use loop.

The NativeBinaries package has a libgit2_filename.txt file that @ethomson added, which let's you have a custom name for libgit2.

If you go into your packages folder, you can open that file up and change the value to point to the name of your local file.

Then, just have your custom libgit2 file copied into the correct NativeBinaries folder in LibGit2Sharp's bin folder. You'd also need to copy it into the Tests bin folder, because at that point VS wouldn't know anything about it, since it wouldn't be listed in the .props file.

I've used a variation of this approach before, and it works pretty well.

[jeffhostetler]

I did something like that in #1193 but using an alternate directory for the .txt and .props files that
referenced the libgit dlls/pdbs and copied them into each bin dir. But that version had too much
baggage from all the cloned .sln/.csproj files.

Manually doing what you describe feels like a pain that anyone who wants to contribute must
figure out how to do and manage. And then there's that time when you make a libgit2 change
and forget to copy over the dll's and waste an hour debugging your C# app (against the old
libraries, again).

I still don't think it addresses the issue of needing to regenerate NativeDllName.cs whenever
the associated libgit2_filename.txt file is modified.

I could see removing the getenv code I added to NativeMethods.cs, so that in the mainline
production case there are no code changes. Only when the new Configuration target is selected
would you see the alternate NativeDllName_LocalDebug.cs.

[ethomson]

Manually doing what you describe feels like a pain that anyone who wants to contribute must
figure out how to do and manage.

Agreed. Shouldn't the nuget package restore directory be an opaque thing? Further, trying to copy one file into the build output directory manually seems wrong, it... well, it seems like exactly what a build is supposed to do.

[bording]

I still don't think it addresses the issue of needing to regenerate NativeDllName.cs whenever
the associated libgit2_filename.txt file is modified.

The MSBuild targets file NativeDllName.targets that takes in libgit2_filename.txt should see that the file has changed and regenerate the NativeDllName.cs file when you rebuild LibGit2Sharp.

Further, trying to copy one file into the build output directory manually seems wrong

Well, sure, but you could always add that copy as a post-build step or something! 😄

I'm not saying that what I suggested is the best way to handle this, just that it is possible to do it without requiring changes to the project!

[jeffhostetler]

Is there something wrong with the CI build servers? One was complaining about machine time limit exceeded and another about a NuGet package dependency.

[ethomson]

I kicked 'em.

On Fri, Sep 25, 2015 at 5:33 PM, Jeff Hostetler notifications@github.com
wrote:

Is there something wrong with the CI build servers? One was complaining
about machine time limit exceeded and another about a NuGet package
dependency.

—
Reply to this email directly or view it on GitHub
#1194 (comment)
.