-
Notifications
You must be signed in to change notification settings - Fork 67
Allow custom DLL names #17
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
Conversation
Allow custom shared library names (eg, `git2-mycompany.dll` instead of `git2-hash.dll`) to allow a single process to potentially load multiple instances of libgit2.
Not everybody has `.` in their path, and we include `Nuget.exe` in the build package. Use that explicitly.
Oh, doh, @nulltoken - I didn't realize that you had a |
Since the changes in libgit2/libgit2sharp#1157 require Other than that, I think this looks good. I don't see anything in this that would break on the mono side of things when using a custom name. Did you by any chance test that to confirm? If not, I can double check that. |
@bording as long as the dllimport's name is regenerated, nothing will break on mono side. |
@Therzok My comment was more about making sure the custom name was actually propagated out to the appropriate places for mono to see it, for example the LibGit2Sharp.dll.config file, and it looks like that is all being handled correctly. |
LibGit2Sharp must know the custom DLL name to be able to load it.
Makes sense. Fixed that up. Thanks. |
If you need to build your own native binaries for some reason, you can | ||
do so easily with the scripts in this repository: | ||
|
||
1. Clone the LibGit2Sharp repository. Do so recursively to ensure that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clone the LibGit2Sharp.NativeBinaries repository
Are you kidding me? This is an amazing README! Of course, you keep it. However, I wouldn't mind some 👀 on #5 😉 |
@@ -38,4 +38,4 @@ if ( -Not (Test-Path $linuxDirectory\*.so) ) | |||
Set-Content $linuxDirectory\addbinaries.here $null | |||
} | |||
|
|||
Nuget.exe Pack nuget.package\NativeBinaries.nuspec -Version $version$versionSuffix -NoPackageAnalysis | |||
.\Nuget.exe Pack nuget.package\NativeBinaries.nuspec -Version $version$versionSuffix -NoPackageAnalysis |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Disclaimer: I'm not a PowerShell wizard. But doesn't the dot-slash notation notation means "here"? Would that be the case, how can we ensure that there's always a NuGet next to this file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Drop this. I forgot that we actually embed NuGet.exe.
@nulltoken I made some changes, but I didn't broadly include #5 yet. There's some very good stuff in there and we should merge the two documents for sure, but I didn't do that as part of this PR. |
@ethomson Neat! |
Like in the pre-NuGet native binary days, we require a way to have a custom libgit2 filename, for example
git2-visualstudio.dll
. This updates the build and update scripts to include support for this, as well as the ability to then output a custom NuGet package suffix so that we do not confuse our binary packages with the official ones.This also adds a
README.md
describing how to work with this system.