Fix for locating lib folder on netcore

[dazinator]

This fixes #1498

[bording]

As I've already mentioned, the lib folder isn't going to be around for .NET Core, so we'll need to come up with some other solution.

[dazinator]

This is aimed to be a hotfix to enable msbuild tasks that leverage libgit2sharp to run under dotnet build, today.

Not trying to dictate / interfere with how you chose to address this longer term / in the future once /lib is removed.

[dazinator]

If the decision is not to adopt this fix, I am happy to switch gitversion over to my own fork, until you have something in place perhaps? It's a bit of a pain but I guess that is the beauty of open source :-). It would mean publishing my temporary fork of libgit2sharp on nuget though - would you allow that?

[bording]

The problem is that this isn't even a good enough temporary fix, because it won't work on non-windows platforms at all.

I think it makes sense to figure out to handle this MSBuild properly vs. temp fixes and forks.

[bording]

Considering that Nerdbank.GitVersioning is working properly with .NET Core without needing changes makes me think the solution isn't to change LibGit2Sharp.

[dazinator]

Nerdbank.Gitversioning works around this issue by adding significant plumbing code to its msbuild tasks for netcore. I would rather see the underyling issues fixed than complicate my msbuild task code. If its fixed it also means we dont need to compile for netcore we can compile for netstandard.

You can see all the workaround logic here: https://github.com/AArnott/Nerdbank.GitVersioning/blob/master/src/MSBuildExtensionTask/ContextAwareTask.cs

The fix I put in place fixes my issue on windows. You are right I did not also try to fix this for other platforms although I'm not sure - if I remoced the windows check, should my fix work on all platforms? It all depends on if assembly has CodeBase and Location available under other platforms.

If libgit2sharp exposed a way for the consumer to configure where it should look for its native assemblies that could be another way to solve this.

[dazinator]

Not sure why the travis build failed.. Seems to be a problem with nuget restore. Don't think it's anything I have permissions to fix.

[dazinator]

The problem is that this isn't even a good enough temporary fix, because it won't work on non-windows platforms at all.

I am closing this, as I think you are right. Fixing this for windows only is not a good enough solution.
If I need this fix for the interim period, I'll publish a temporary nuget package from my fork, which I will leave unlisted on nuget, and clearly named with my fork.

[bording]

If libgit2sharp exposed a way for the consumer to configure where it should look for its native assemblies that could be another way to solve this.

FYI, a primary blocker from doing this is that the library search path can't be altered from within the process on unix like it can be from Windows. Once the process has been started, it's too late to alter it.

[dazinator]

FYI, a primary blocker from doing this is that the library search path can't be altered from within the process on unix like it can be from Windows. Once the process has been started, it's too late to alter it.

Thanks for the info, that makes sense.

I think I have come to the conclusion that the only way to handle this for the msbuild task scenario, accross all platforms, is to have the msbuild task assembly loaded into, and executed from, a custom 'AssemblyLoadContext':
https://github.com/dotnet/coreclr/blob/master/Documentation/design-docs/assemblyloadcontext.md#pinvoke-resolution

Which can then implement that method to resolve native lib's locally to the task assembly.

I've raised an issue over on UtilPack: stazz/UtilPack#14 as I think it's something the msbuild task factory can take care of there.

[bording]

I think I have come to the conclusion that the only way to handle this for the msbuild task scenario, accross all platforms, is to have the msbuild task assembly loaded into, and executed from, a custom 'AssemblyLoadContext':

That does appear to be how Nerdbank.GitVersioning has handled it: https://github.com/AArnott/Nerdbank.GitVersioning/blob/master/src/MSBuildExtensionTask/ContextAwareTask.cs#L72

[dazinator]

Yup. I just feel strongly that putting this logic in the msbuild task itself is probably the wrong place. MsBuild tasks shouldn't have to be concerned with also being a proxy to themselves imho - they have enough to worry about. I also am not interested in compiling for netcore, I want to have a single compilation for netstandard! Huge respect to AArnott for the solution though - I am not dissing, just expressing my artistic licence :-)