Effort towards making this a PCL

[Therzok]

What would be your standpoint on libgit2sharp becoming a PCL? (Being able to be used in mobile devices, silverlight, etc).

If we want this, what profile should we target?

[kzu]

👍 would love to see this happening

[whoisj]

How would this work? If you're considering Windows Phone or UWP apps, they will not be able to load the libgit2.dll due to it's Win32 bindings.

[yufeih]

👍 +1

At least it should target UWP (Win 10 + Win 10 Mobile) and Xamarin (iOS + Android).

[shiftkey]

Seconding what @whoisj said - I'd love to understand more about the restrictions/possibilities for loading unmanged assemblies into the app on these platforms.

While we could work towards targeting these platforms by addressing API issues in libgit2sharp, without the underlying support for being able to P/Invoke git2*.dll there it really limits what we can do here.

[Therzok]

Hmm, we could start out with a really restricting platform-wise, but permissive feature-wise profile (let's say Android, iOS, and whatever supports P/Invoke), and work out a solution for the others and gradually increasing the platforms supported?

I'm no master of the limitations of UWP, and possibly there is a solution of exposing libgit2 functionality through managed-C++ or something?

[bording]

I'm no master of the limitations of UWP, and possibly there is a solution of exposing libgit2 functionality through managed-C++ or something?

Feasibility aside, having a managed version of libgit2 would solve a ton of problems!

[ethomson]

Feasibility aside, having a managed version of libgit2 would solve a ton of problems!

Out of curiosity (and also leaving feasibility of this aside): what sort of problems are you having that this would solve?

[kzu]

Basically, having third party libraries and frameworks (I.e. a document
storage library, a git high level library, a dropbox alternative
api/library, that is a cloud storage api backed by git, etc.) that could
take a dependency of this as a PCL and ship themselves as PCLs, which can
be consumed by any app in any supported platform.

On Sat, Aug 29, 2015, 3:02 PM Edward Thomson [email protected]
wrote:

Feasibility aside, having a managed version of libgit2 would solve a ton
of problems!

Out of curiosity (and also leaving feasibility of this aside): what sort
of problems are you having that this would solve?

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

[bording]

Out of curiosity (and also leaving feasibility of this aside): what sort of problems are you having that this would solve?

In my case I was speaking a bit more generally than the specific topic of PCL conversion, though it certainly helps there too.

Most of my contributions so far have been around improving the cross platform story, making things more likely to just work without effort on the consumer's part. The primary focus has been on how those bits get delivered, the nativebinaries nuget package.

Having to depend on platform-specific native binaries adds a lot of complexity to the project vs. it just being managed assemblies all the way down. There are a lot of moving pieces there that can break in ways that can be difficult for someone who doesn't have knowledge of the internals of the project to understand.

The main area where I've seen this tends to happen is on the mono side of things. There are all sorts of "fun" issues around how mono interacts with the native library loaders ( #1170 for example).

Another issue there is that for the linux binary, it requires OpenSSL. The version of the binary we're including in the nuget package works fine when you use it on Ubuntu, but the OpenSSL version that CentOS ships has a completely different soname, so our binary doesn't work there. (The second problem brought up here) I'm still working though how to get that one solved, but I think it will end requiring us to include OpenSSL binaries in the nativebinaries nuget package.

Even on Windows, it can break down in various ways, particularly around publishing. People have had problems with Web Publishing, ClickOnce, and that all comes down to those mechanisms not understanding that they need to include the native binaries in their output.

Ultimately, my goal is to try and make a consumer of LibGit2Sharp not care about how it's implemented, and just be able to use it on windows or linux, or wherever and not have to care about how it works internally to make that happen. Having a completely managed libgit2 dependency would make most of what I just brought up a non-issue! 😄

Ok, that's probably more than enough for a thread that isn't specifically about this, apologies for the diversion!

[Therzok]

Having a completely managed libgit2 dependency would make most of what I just brought up a non-issue! 😄

This is more complicated than it sounds. Managed C++ would only go a short way, enabling usage on Windows. Moving to a managed C# or whatever compiles to IL would be really resource-heavy in terms of development.

[whoisj]

While a proponent of C#, a libgit2 library developed in it would leave all of the non-.NET bindings out in the cold. Not a very friendly thing to do. Until some magic day when .NET can provide cdecl entry points without the need for an installed run time, I cannot imagine replacing the native library with a .NET version.

[carlosmn]

@bording a lot of the issue you describe is not due to libgit2 being unmanaged but by its dependencies being unmanaged. If libgit2sharp were to have a managed https and ssh backend, it would not need OpenSSL or libssh2 available on the host system.

Vendoring OpenSSL (or any crypto library) is not something to be taken lightly. You have to keep up to date with all of the security advisories and make sure to update the version you provide.

If we could make libgit2 managed, that would indeed solve many issues, but I don't know that we can have the same codebase do both managed and unmanaged. Making the network dependencies be managed does however go a long way towards solving the problems.

[carlosmn]

I'm closing this since nothing has happened. As long as it works for the systems where we already use it, we're not against having PCL support. But someone should do it and propose a PR with whatever changes might be necessary.

[kzu]

I think #1318 pretty much fixes this, I'd think? @Therzok wouldn't it?

[Therzok]

Yeah. .NETStandard fixes that.

[ethomson]

This is already closed, so there's nothing more to do here. 🎉