libgit2sharp icon indicating copy to clipboard operation
libgit2sharp copied to clipboard

Unable to load DLL 'git2'

Open b-twis opened this issue 5 years ago • 6 comments

Hi All,

I know there are a number of similar issues listed, but non quite fit my scenario.

I have a system (that I cant change) that stores code and dlls (binary blob) in a database. The data is extracted and a VS Solution is generated. As such I do not have the ability to use NuGet or to force the git2-4aecb64.dll into the specific folders required for it to work. Additionally the git2.dll is renamed (also out of my control) with a UID on the end. eg. git2-4aecb64_Server_c8l_S0Kakc7Do5PhhDGPhxoObuMgSRw2detcnbwdOuQ.dll

So, based on other incidents raised, I understandably get the following error when the git-xxx.dll is included in the root folder next to LibGit2Sharp.dll

System.Web.Services.Protocols.SoapException: Server was unable to process request. ---> System.TypeInitializationException: The type initializer for 'LibGit2Sharp.Core.NativeMethods' threw an exception. ---> System.DllNotFoundException: Unable to load DLL 'git2-4aecb64': The specified module could not be found. (Exception from HRESULT: 0x8007007E)at LibGit2Sharp.Core.NativeMethods.git_libgit2_init()at LibGit2Sharp.Core.NativeMethods.LibraryLifetimeObject..ctor()at LibGit2Sharp.Core.NativeMethods..cctor() --- End of inner exception stack trace ---

Does anyone have any suggestions for resolving this?

Possibly a config item I can pass to LibGit2Sharp that would take a relative path to the git2.dll?

Or could I build a combined DLL?

Reproduction steps

  1. Create new VS 2017 c# console app
  2. Manually add Reference to LibGit2Sharp.dll and then copy git2-4aecb64.dll to the bin folder
  3. Try to Clone a Repository using below code
var cloneOptions = new CloneOptions { BranchName = "master", Checkout = true };
cloneOptions.CredentialsProvider = (_url, _user, _cred) => new UsernamePasswordCredentials { Username = username, Password = pass };
string localFolder = @"C:\Repos\test"; 
var cloneResult = LibGit2Sharp.Repository.Clone(url, localFolder, cloneOptions);

Expected behavior

Repository is cloned

Actual behavior

Exception is raised System.Web.Services.Protocols.SoapException: Server was unable to process request. ---> System.TypeInitializationException: The type initializer for 'LibGit2Sharp.Core.NativeMethods' threw an exception. ---> System.DllNotFoundException: Unable to load DLL 'git2-4aecb64': The specified module could not be found. (Exception from HRESULT: 0x8007007E)at LibGit2Sharp.Core.NativeMethods.git_libgit2_init()at LibGit2Sharp.Core.NativeMethods.LibraryLifetimeObject..ctor()at LibGit2Sharp.Core.NativeMethods..cctor() --- End of inner exception stack trace ---

Version of LibGit2Sharp (release number or SHA1)

Versions pulled from NuGet package LibGit2Sharp - version="0.25.4" LibGit2Sharp.NativeBinaries - version="1.0.252"

Operating system(s) tested; .NET runtime tested

Windows 10 with .Net 4.7

Thanks,

Basil

b-twis avatar Jan 18 '19 14:01 b-twis

If you have no control over how the native libgit2 is renamed, then LibGit2Sharp is not going to work for you. The managed LibGit2Sharp assembly has to P/Invoke into the native dll, and it has to know what the name of that dll is going to be when we compile LibGit2Sharp.

If you have git2-4aecb64_Server_c8l_S0Kakc7Do5PhhDGPhxoObuMgSRw2detcnbwdOuQ.dll when we're looking for git2-4aecb64.dll, then those aren't the same dlls, and LibGit2Sharp can't use it.

bording avatar Jan 18 '19 17:01 bording

I'm also having this issue. I'm guessing it has something to do with how nuget processes the install, as it works fine on my original build machine, however when I clone the repository that uses libgit2sharp on another machine and start to edit it, I get this same exception, except with a different hash.

I've made this work by cloning LibGit2Sharp and referencing the libgit2sharp\LibGit2Sharp\LibGit2Sharp.csproj file directly by going to the solution, and adding existing project.

Going back to what @bording stated, i believe the problem is coming from the nuget package. I would suspect that nuget has control over the naming of the resulting dll, and thus, the nuget package should probably be fixed.

shiftybit avatar May 07 '19 17:05 shiftybit

@wolfbyte This issue is about renaming the libgit2 assembly and then not being able to load it from LibGit2Sharp. If you aren't renaming the file from the package, then you have another problem. Please open a new issue instead.

bording avatar May 07 '19 18:05 bording

Nuget seems to rename it during each build as part of the process. Steps to reproduce. Start a new project. Add the libgit2sharp package. Compile. Push to github. On another computer git clone repo. The nuget package will be retrieved, but the dll will be compiled under a different name.

The application will build but throws an exception whenever it gets to the point of trying to use the dll

On Tue, May 7, 2019, 2:19 PM Brandon Ording [email protected] wrote:

@wolfbyte https://github.com/wolfbyte This issue is about renaming the libgit2 assembly and then not being able to load it from LibGit2Sharp. If you aren't renaming the file from the package, then you have another problem. Please open a new issue instead.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/libgit2/libgit2sharp/issues/1656#issuecomment-490192453, or mute the thread https://github.com/notifications/unsubscribe-auth/ABIPTLEF5CWY3WS4RU5OMRLPUHB3JANCNFSM4GQ72ZEQ .

shiftybit avatar May 07 '19 20:05 shiftybit

@wolfbyte What you're saying doesn't make sense. The files in the package aren't compiled when you are referencing them, so they aren't going to change dynamically like that.

Some more information is going to be required here. Please provide more solid details, like screenshots or some specific error messages.

bording avatar May 07 '19 21:05 bording

I'm just leaving this comment here for future reference, not sure if it's fixed in the latest version.

I experienced the same issue using a new project. The issue here is that the native DLL's are not copied to the target directory. I'm not sure why; the directories themselves are created fine. Once the runtime DLL's are copied, everything works like it's supposed to.

atlaste avatar Jan 29 '21 09:01 atlaste