[anaisbetts]

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]

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?

[anaisbetts]

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)

[anaisbetts]

Take my changggggggggeeeee