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

Extract libgit2 at runtime #3

Closed
wants to merge 1 commit into
base: development
from

Conversation

Projects
None yet
2 participants
@paulcbetts
Copy link

paulcbetts commented Sep 30, 2011

Unfortunately, while Visual Studio has many solutions for ensuring that
your managed dependent DLLs get shipped alongside your project, it's got
absolutely nothing to ensure your native P/Invoke DLLs get shipped.

The easiest, most foolproof method to ensure that a managed DLL has its
native dependency regardless of how it is built or shipped is to embed
it as a resource and extract it before use. This patch ensures that
LibGit2Sharp will always have the corresponding version of git2.dll.

Add libgit2 Loading At Runtime
Unfortunately, while Visual Studio has many solutions for ensuring that
your managed dependent DLLs get shipped alongside your project, it's got
absolutely nothing to ensure your native P/Invoke DLLs get shipped.

The easiest, most foolproof method to ensure that a managed DLL has its
native dependency regardless of how it is built or shipped is to embed
it as a resource and extract it before use. This patch ensures that
LibGit2Sharp will always have the corresponding version of git2.dll.
@nulltoken

This comment has been minimized.

Copy link

nulltoken commented on 5a7239f Oct 2, 2011

That's brilliant! I like it very much.... even if it doesn't compile ;)

Two quickies:

  • Do you know how would the "extract from resource" mechanism behave in hosted/medium-trust environment? Would it be compliant as well with Azure hosting policy?
  • I'd prefer no to mess with the environment variables of the user. I've commented the Environment.SetEnvironmentVariable call, removed the GetEntryAssembly call (but kept the GetExecutingAssembly one) and successfully succeeded in running the tests from both TestDriven and Resharper. Can you think of a corner case usage that would compel us to alter the "PATH" variable?

This comment has been minimized.

Copy link
Owner Author

paulcbetts replied Oct 2, 2011

Do you know how would the "extract from resource" mechanism behave in hosted/medium-trust environment? Would it be compliant as well with Azure hosting policy?

Depends, but it probably would work. I make no guarantees though.

I'd prefer not to mess with the environment variables of the user

This is changing the environment variables of the process, it doesn't affect any other user. It's important to leave this in because we can't guarantee that the DLL will be in the Loader search path otherwise. On my machine, not doing this means all the unit tests fail.

removed the GetEntryAssembly call (but kept the GetExecutingAssembly one)

Keep this too, the entry assembly is one of the places searched in the Loader search path.

@nulltoken

This comment has been minimized.

Copy link

nulltoken commented Oct 3, 2011

Do you know how would the "extract from resource" mechanism behave in hosted/medium-trust environment? Would it be compliant as well with Azure hosting policy?

Depends, but it probably would work. I make no guarantees though.

Hm. I've made some research. Considering the "by default" configuration of medium trust hosted environment and Azure, extracting (either in the app/bin dir or in the temp directory) would make us jump through many hoops.

I'd prefer not to mess with the environment variables of the user

This is changing the environment variables of the process, it doesn't affect any other user. It's important to leave this in because we can't guarantee that the DLL will be in the Loader search path otherwise. On my machine, not doing this >means all the unit tests fail.

Sorry about this. You're right.... and inspiring!

So, if we strike off the extraction, we go back to SqlCe scenario: Next to the managed assembly, a folder Native Libs which contains two subfolders x86 and amd64, each of them containing the appropriate version of git2.dll.

However, instead on relying on LoadLibrary, it looks like that simply altering the process PATH environment variable in the static constructor would do the trick.

The added path would be a combination of the original location of LibGit2Sharp (new Uri(Assembly.GetExecutingAssembly().CodeBase).LocalPath or something similar which should circumvent shadow copying) and the correct folder hierarchy based on the size of IntPtr.

Do you think this would work on your machine?

@paulcbetts

This comment has been minimized.

Copy link
Author

paulcbetts commented Oct 3, 2011

Hm. I've made some research. Considering the "by default" configuration of medium trust hosted environment and Azure, extracting (either in the app/bin dir or in the temp directory) would make us jump through many hoops.

They can always deploy libgit2.dll themselves. There's no reason for us to bend over backwards to support a scenario that is marginal at best.

So, if we strike off the extraction, we go back to SqlCe scenario: Next to the managed assembly, a folder Native Libs which contains two subfolders x86 and amd64, each of them containing the appropriate version of git2.dll.
Seems reasonable, though I think we can solve the amd64 issue once there's a 64-bit version of git2.dll

Paul Betts paul@paulbetts.org

On Monday, October 3, 2011 at 1:11 PM, nulltoken wrote:

Do you know how would the "extract from resource" mechanism behave in hosted/medium-trust environment? Would it be compliant as well with Azure hosting policy?

Depends, but it probably would work. I make no guarantees though.

Hm. I've made some research. Considering the "by default" configuration of medium trust hosted environment and Azure, extracting (either in the app/bin dir or in the temp directory) would make us jump through many hoops.

I'd prefer not to mess with the environment variables of the user

This is changing the environment variables of the process, it doesn't affect any other user. It's important to leave this in because we can't guarantee that the DLL will be in the Loader search path otherwise. On my machine, not doing this >means all the unit tests fail.

Sorry about this. You're right.... and inspiring!

So, if we strike off the extraction, we go back to SqlCe scenario: Next to the managed assembly, a folder Native Libs which contains two subfolders x86 and amd64, each of them containing the appropriate version of git2.dll.

However, instead on relying on LoadLibrary, it looks like that simply altering the process PATH environment variable in the static constructor would do the trick.

The added path would be a combination of the original location of LibGit2Sharp (new Uri(Assembly.GetExecutingAssembly().CodeBase).LocalPath or something similar which should circumvent shadow copying) and the correct folder hierarchy based on the size of IntPtr.

Do you think this would work on your machine?

Reply to this email directly or view it on GitHub:
#3 (comment)

@paulcbetts

This comment has been minimized.

Copy link
Author

paulcbetts commented Oct 24, 2011

Take my changggggggggeeeee

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment