FilePathMarshaler must be used on a FilePath

[SimonCropp]

I am getting an exception "FilePathMarshaler must be used on a FilePath"

Which is coming from here

    public override IntPtr MarshalManagedToNative(object managedObj)
    {
        if (managedObj == null)
        {
            return IntPtr.Zero;
        }

        if (!(managedObj is FilePath))
        {
            throw new MarshalDirectiveException("FilePathMarshaler must be used on a FilePath.");
        }

        return StringToNative(((FilePath)managedObj).Posix);
    }

The interesting thing is if i set a breakpoint in that method and use the immediate window I can do the following

managedObj is FilePath is true

managedObj.GetType().FullName is "LibGit2Sharp.Core.FilePath"

So I have no idea why it is throwing an exception.

[dahlbyk]

Can you post the full LibGit2Sharp stack trace?

[SimonCropp]

Exception:
FilePathMarshaler must be used on a FilePath.
StackTrace:
at LibGit2Sharp.Core.FilePathMarshaler.MarshalManagedToNative(Object managedObj) in :line 0
at System.StubHelpers.MngdRefCustomMarshaler.ConvertContentsToNative(IntPtr pMarshalState, Object& pManagedHome, IntPtr pNativeHome)
at LibGit2Sharp.Core.NativeMethods.git_repository_open(RepositorySafeHandle& repository, FilePath path)
at LibGit2Sharp.Repository..ctor(String path, RepositoryOptions options) in :line 0

[nulltoken]

@SimonCropp Would you also agree to share the content of the path parameter?

[SimonCropp]

H:\Fody.git

[nulltoken]

I tried to reproduce the issue. But, so far, I haven't been able to do so and will need a little help from you.

• What version of LibGit2Sharp are you running? (Latest NuGet package or vNext branch?)
• Could you please describe some setup steps that could help reproduce the issue you're encountering?

Below is what I have tested. Can you check that this is passing as well in your environment?

Clone Fody into a bare local repository:

$ cd /d/Temp

$ git clone --bare http://github.com/SimonCropp/Fody.git
Cloning into bare repository 'Fody.git'...
remote: Counting objects: 1380, done.
remote: Compressing objects: 100% (752/752), done.
remote: Total 1380 (delta 863), reused 1105 (delta 588)
Receiving objects: 100% (1380/1380), 2.81 MiB | 165 KiB/s, done.
Resolving deltas: 100% (863/863), done.

Create a subst drive pointing to the clone location:

Setting environment for using Microsoft Visual Studio 2010 x86 tools.

C:\Program Files\Microsoft Visual Studio 10.0\VC>subst H: D:\Temp

C:\Program Files\Microsoft Visual Studio 10.0\VC>dir H:
 Volume in drive H has no label.
 Volume Serial Number is 9E9E-1A02

 Directory of H:\

06/11/2012  10:52    <DIR>          .
06/11/2012  10:52    <DIR>          ..
06/11/2012  10:52    <DIR>          Fody.git
               0 File(s)              0 bytes
               3 Dir(s)  134 385 594 368 bytes free

Following test pass:

[Fact]
public void CanOpenBareRepoOnSubstDrive()
{
    using (var repo = new Repository(@"H:\Fody.git"))
    {
        Assert.NotNull(repo);
    }
}

Create a network share pointing to the clone location:

C:\Program Files\Microsoft Visual Studio 10.0\VC>net share TempFody=D:\Temp
TempFody was shared successfully.

C:\Program Files\Microsoft Visual Studio 10.0\VC>dir \\localhost\TempFody
 Volume in drive \\localhost\TempFody has no label.
 Volume Serial Number is 9E9E-1A02

 Directory of \\localhost\TempFody

06/11/2012  10:52    <DIR>          .
06/11/2012  10:52    <DIR>          ..
06/11/2012  10:52    <DIR>          Fody.git
               0 File(s)              0 bytes
               3 Dir(s)  134 385 074 176 bytes free

Following test pass:

[Fact]
public void CanOpenBareRepoFromAnUncPath()
{
    using (var repo = new Repository(@"\\localhost\TempFody\Fody.git"))
    {
        Assert.NotNull(repo);
    }
}

Then, using Windows 7 GUI, I mapped \\localhost\TempFody to the J: drive.
The J:drive correctly appeared in the explorer.

Following test pass:

[Fact]
public void CanOpenBareRepoFromAMappedNetWorkDrive()
{
    using (var repo = new Repository(@"J:\Fody.git"))
    {
        Assert.NotNull(repo);
    }
}

[SimonCropp]

hold of on this one for a while. I will put the effort into creating a proper repro.

[dahlbyk]

Could add the type of managedObj to the exception message to maybe make it easier to debug?

[SimonCropp]

After much tinkering this is my bug. Turns out I had two copies of the libgit2sharp dll loaded. hence the type comparison was failing.

Sorry for the hassle and thanks for the support.

[dahlbyk]

I'm fuzzy on how .NET is expected to behave when similar unsigned assemblies are referenced in the same domain, but @shiftkey's issue/resolution suggests this might be something we need to have an answer for. One would expect more "competing" Git-related VS extensions to appear over time...

/cc @martinwoodward @xpaulbettsx

[martinwoodward]

Urgh. I'm going to summon @phkelley and @jamill on this one as well. My personal knowledge gets very fuzzy in this area especially when we start talking about how the git2.dll loading is managed. Just to be clear, the scenario we are concerned about is:

1. User running Visual Studio 2012 with the VS Tools for Git extension installed or user running a future version of Visual Studio where the Git tooling is built in.
2. User also installs one or more extensions which are dependent on a feature added that has been added into a custom or newer version of LibGit2Sharp + LibGit2 which the extension provider(s) are distributing with their plug-in

Are we going to have dll loading issues?

[shiftkey]

Git4VS is running v0.10 of libgit2sharp. SaveAllTheTime is running v0.11.

Oh, and testing SaveAllTheTime in the Experimental VS Instance didn't help identify the issue because the Git4VS extension wasn't loaded. Good times.

[shiftkey]

@martinwoodward Yes, that's the scenario I just encountered.

[martinwoodward]

Thanks @shiftkey. Guess this is more than just hypothesis then - urgh :-(

FWIW, we might end up creating a parallel MS Connect bug but for now let's carry on here as it also has general interest as evidenced by this particular issue which didn't involve the VS Tools for Git (I think) and VS Extensions.

[nulltoken]

I might have a solution that would fix this.

The way we upgrade LibGit2Sharp with the latest libgit2 binaries relies on the UpdateLibgit2ToSha.ps1 script. Among other things, this takes care of building libgit2 and moving the generated dlls in the correct tree structure.

The idea would be to update this script and make it rename the generated .dll/.pdb files to make them unique, naming them after the corresponding libgit2 commit sha. Thus, instead of making LibGit2Sharp probe for a generic git2.dll binary, it would search for a git2-{short_commit_sha}.dll one (eg. git2-ac0ffee.dll). This relies on the (unverified) assumption that the link between a .dll and its corresponding .pdb is only based on the name of the files.

Provided the solution works and actually makes sense, this would allow different future versions of LibGit2Sharp to run side by side.

I discussed this subject with @ben and he's going to draft something along those lines. Hopefully, we'll release a v0.11.1 NuGet package within the following days which should fix this.

How do you feel about this?

[nulltoken]

/cc @spraints @KindDragon

[anaisbetts]

Yep, I'm now hitting this bug in SaveAllTheTime with anyone who has the Git Tools for VS installed, which ships lg2s too :-/

[anaisbetts]

This is actually pretty problematic - even if I downgrade SaveAllTheTime's libgit2sharp to 0.10, I'm hitting this crash.

[nulltoken]

@ben worked on #430 to tackle this issue.

[nulltoken]

Closed by 48ea4d5