GitVersion.CommandLine does not work on OS X

[eatdrinksleepcode]

Steps to reproduce:

1. mono nuget.exe install GitVersion.CommandLine -Version 3.5.2
2. mono ./GitVersion.CommandLine.3.5.2/tools/GitVersion.exe

Output:

System.TypeInitializationException: The type initializer for 'LibGit2Sharp.Core.NativeMethods' threw an exception. ---> System.DllNotFoundException: git2-381caf5
at (wrapper managed-to-native) LibGit2Sharp.Core.NativeMethods:git_libgit2_init ()
at LibGit2Sharp.Core.NativeMethods+LibraryLifetimeObject..ctor () <0x1fa8ae0 + 0x0000b> in :0
at LibGit2Sharp.Core.NativeMethods..cctor () <0x1fa8908 + 0x00107> in :0

Comparing the GitVersion.CommandLine package to the GitVersionTask package (which does work on OS X), the difference is that GitVersionTask includes a GitVersionTask.dll.config file which uses the Mono dllmap capability to map libgit2 for each system; GitVersion.CommandLine does not contain a similar config file. Copying the config file from GitVersionTask to GitVersion.CommandLine (and renaming it to GitVersion.exe.config) causes GitVersion.exe to work correctly.

I will look into creating a PR with a fix to the GitVersion.CommandLine package in the next couple of days, unless someone beats me to it.

Also, since the docs say to open an issue about why I want to use the GitVersion.CommandLine package, let me add that note here:

• I cannot use the Chocolatey package for two reasons:
  • Different projects on my (or any other) machine may be using different versions of GitVersion, making it dangerous to rely on a GitVersion that is installed machine-wide
  • I am building on OS X
• I don't want to use the GitVersionTask package, because it only works in MSBuild. I do not want determining my version number to be tied to MSBuild, because MSBuild is not my primary build tool (although like most .NET projects I am dependent on it for compilation for the time being). For example, there is no easy way to pass the version from GitVersion to my "nuget pack" command.
  • The typical solution of using the "$version$" replacement token in the nuspec to substitute the version from the assembly only works when packing based on a csproj, which doesn't work when running NuGet in mono. I am forced to pack based on the nuspec, and therefore must pass the version directly.
• I don't want to check in GitVersion.exe to my source repository for the same reasons I don't want to check in any external dependencies to my source repository: I lose the ability to easily track and update the versions of my dependencies that NuGet gives me.

For these reasons, the GitVersion.CommandLine package is the best solution for me. Hopefully it can be maintained as a first-class citizen in the future.

[eatdrinksleepcode]

Unfortunately, there does not appear to be a simple solution to this (perhaps why it was not done at the same time as GitVersionTask). Adding a GitVersion.exe.config with the entries fails on .NET because the entries are not valid. The reason GitVersionTask works for both .NET and Mono is that .NET does not look for ".dll.config" files, so including the file to make Mono work does not break .NET.

There are two possible solutions to this that I can think of - modify NuGetCommandLineBuild to:

A) move GitVersion.exe down in to OS-specific directories, which would allow OS-specific config files.
B) exclude LibGit2Sharp from ILRepack and include the entries in LibGit2Sharp.dll.config

I lean towards (B), but that is partially because I am not entirely certain what value ILRepack is providing in the GitVersion.CommandLine scenario. If I can get some direction from the maintainers on which way to go, I can put together the PR.

[eatdrinksleepcode]

After attempting both solutions, it has become clear that A is not a particularly viable solution: the mappings defined in the LibGit2Sharp.dll.config file are relative, so moving the GitVersion.exe config down would require at minimum an extra level of nesting (see below), which would not only be redundant, but would also make the path to invoke the exe OS-specific. Otherwise GitVersion would have to stop using the config file that comes from the LibGit2Sharp package and use its own modified config file instead, which doesn't seem like a good idea either.

The only way (A) could work is:

• tools\
  • win32\
    • GitVersion.exe
    • lib\
      • win32\
        • x86\
          • git2-381caf5.dll
  • osx\
    • GitVersion.exe
    • GitVersion.exe.config
    • lib\
      • osx\
        • libgit2-381caf5.dylib

Based on this finding, I plan to submit a PR which implements (B) soon.

[asbjornu]

@eatdrinksleepcode Thanks for digging into this. Have you looked at libgit2/libgit2sharp#1170 and libgit2/libgit2sharp#1298 (related to #816 and #856) which seems related to the issues you're having? I'm not sure, but I think this might be a problem that should be solved in LibGit2Sharp and not in GitVersion. Look through the discussions in the referenced issues and let me know what you figure out! 😃

[eatdrinksleepcode]

@asbjornu I have seen the other work for supporting mono. Ultimately though, this is something that has to be fixed in GitVersion. Fundamentally, LibGit2Sharp relies on a .dll.config file to work on Mono (and on that config file not being loaded by the full framework to support cross-platform). GitVersion is breaking that pattern by using ILRepack to merge LibGit2Sharp into GitVersion.exe; .exe.config files are loaded by the full framework, so there is no way to support both the .NET Framework and Mono with the same package as long as LibGit2Sharp is being merged into GitVersion.exe (except as outlined previously; the other options are even worse than excluding LibGit2Sharp from the merge).

I am putting together the PR now.

[asbjornu]

@eatdrinksleepcode Ok, thanks for the explanation. Looking forward to seeing the PR!

[asbjornu]

@eatdrinksleepcode How is that pull request coming along? A use case has come up where using GitVersion on the OS X command line would be very useful, which made me create this Homebrew formula that I would love to pull-request. The problem is, as you've discovered, GitVersion.exe fails on OS X. 😃

[eatdrinksleepcode]

I have a working version but got sidetracked trying to refactor the project file :) I will post the basic PR to get it working in the next 36 hours, and put off the rest until later.

[asbjornu]

@eatdrinksleepcode Excellent! 👍

[arlo-egg]

@asbjornu I am interested in trying GitVersion on Mac OSX using your homebrew formula. How can I try it out?

[asbjornu]

@arlo-egg I haven't completed the formula yet, but I will as soon as possible next week. I'll hopefully remember to let you know once it's done. 😄

[asbjornu]

@arlo-egg:

Homebrew/homebrew-core#3709 is merged and ready to go. 😄

[mclang]

Hello

This issue is closed, but I'm wondering if this fix should work in Linux with GitVersion 3.6.4? Seemingly not because I'm hitting into same problem :(

[asbjornu]

@mclang: I haven't tested version 3.6.4 on Linux, so I don't know. Our continuous integration build on Travis runs the tests on Linux, though, so it should work. Can you please create a new issue with details about what error messages you get, your configuration and perhaps even what repository it is failing in (if public)?