Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exception when using it inside a Visual Studio 2022 Extensibility project #2103

Open
luislhg opened this issue Jun 10, 2024 · 6 comments
Open

Comments

@luislhg
Copy link

luislhg commented Jun 10, 2024

Hello, I'm unable to this this package within my Visual Studio 2022 extension.

Reproduction steps

  1. Create a new VisualStudio.Extensibiltiy Extension project (VS 2022)
  2. Add a reference to <PackageReference Include="LibGit2Sharp" Version="0.30.0"/>
  3. Add using (var repo = new Repository(repoDir)) to a command

Sample project:
ExtensibilityNativeLibraries.zip

Expected behavior

To initialize the repo instance

Actual behavior

Exception
The type initializer for 'LibGit2Sharp.Core.NativeMethods' threw an exception.
InnerException = {"Unable to load DLL 'git2-a418d9d' or one of its dependencies: Não foi possível encontrar o módulo especificado. (0x8007007E)"}

Version of LibGit2Sharp (release number or SHA1)

0.30.0

Operating system(s) tested; .NET runtime tested

Windows 11, .NET 8

@ethomson
Copy link
Member

Are you shipping the native libgit2 DLL as part of your vsix?

@luislhg
Copy link
Author

luislhg commented Jun 10, 2024

Are you shipping the native libgit2 DLL as part of your vsix?

I'm not sure how that would wok in the new Extensibility API project with .NET 8?
It fails in debug already as you can see in the sample project.

@luislhg
Copy link
Author

luislhg commented Jul 18, 2024

Just wanted to explain that I ran the sample and;
Yes, the native libgit2 are being exported with the vsix.
ExtensibilityNativeLibraries.dll is the extension assembly, and it has all the proper folders and libgit2 sharp, but when running the extension it just doesn't work or find it.

image

Workaround/Solution
I used GlobalSettings.NativeLibraryPath to specify it manually and then it worked

string nativeLibraryPath = Path.Combine(assemblyFolder, "runtimes", "win-x64", "native");
GlobalSettings.NativeLibraryPath = nativeLibraryPath;

The final question is: Is it expected that I have to specify the folder like this for a standard/default location?
Note: there is a working sample project attached to the issue.

Other than that, this issue is solved, and the solution is above in case anyone else stumbles over this.

@ethomson
Copy link
Member

Thanks @luislhg thats very helpful. Is there a way to detect when we're running in this environment so that we can load from the proper location in LibGit2Sharp?

@luislhg
Copy link
Author

luislhg commented Jul 27, 2024

Hum, I'm not sure what the difference is in this environment
All that I had to do/specify in the NativeLibraryPath was this for it to work in the VS Extension:

string assemblyFolder = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location)[..^2];
GlobalSettings.NativeLibraryPath = Path.Combine(assemblyFolder, "runtimes", "win-x64", "native");

Which is the normal path I'd expect it to automatically pick up in my own executing folder...

@bording
Copy link
Member

bording commented Jul 27, 2024

I wasn't familiar with the extension model you were using, so I took a quick look over the documentation in the repo.

It looks like it's a new out-of-proc model for VS extensions, which means you're no longer limited to targeting .NET Framework, so that's cool.

However, since the extension wasn't able to automatically find the native libraries, that implies that that when they are loading the extension, they aren't properly looking at the deps.json file of the extension.

If you look at your ExtensibilityNativeLibraries.deps.json in the sample you provided, you'll see that all of the LibGit2Sharp native runtime information is in there, and that info is used by the .NET runtime to load the correct native library for you.

It looks like however the VSExtensibility system is loading the extensions, they aren't picking up that information, so the native library location is unknown until you manually set it via NativeLibraryPath.

I don't know the details of how they are loading the extension assemblies, but there are ways available to them to ensure they are referencing the deps.json files of the extension assemblies. If they did that, then the proper native library would loaded.

I was going to suggest opening an issue, but I see that you already have.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants