Doesn't work with projects on SMB shares

[DragonQ]

I replaced SemanticGit with GitInfo in my project since the former was marked as obsolete. However, when I build my project, which resides on an SMB share, it just produces an error:

The expression "[System.IO.File]::ReadAllText(Z:\VB Projects\Music Folder Syncer\Project.git\HEAD)" cannot be evaluated. Could not find a part of the path 'Z:\VB Projects\Music Folder Syncer\Project.git\HEAD'.

Is this a bug or misconfiguration on my part? SemanticGit worked fine.

[kzu]

There seems to be a missing \ between Project and .git, no?

[kzu]

Could you please attach to the issue a diagnostics build containing the output of running the _Git* targets? You can achieve this by invoking msbuild /v:diag /t:GitVersion from the .csproj folder, for example. Pasting the url to a gist should be enough, thanks!

[DragonQ]

Ah, true. Sounds like a path concatenation error. Are you using IO.Path.Combine for that sort of thing?

I get 59 errors in my project when building with /v:diag, although it builds and runs fine from within Visual Studio. It doesn't build GitVersion though, just saying Target "GitVersion" skipped. Previously built successfully. If I specify GitVersion or GitInfo as the target, it just says they do not exist in the project. I assume this is because I just use NuGet to grab the GitInfo package rather than building it myself?

[kzu]

Yes, I use Path all over since it's the only way it can possibly work on the Mac too ;).

The failure seems to come from this line: https://github.com/kzu/GitInfo/blob/master/src/GitInfo/build/GitInfo.targets#L242

Which I fail to see how it can possibly fail.

When you install the GitInfo nuget package into your project, now you project effectively contains all its targets, which you can invoke from msbuild just as if they were defined in the .csproj or any other imports (like Build, which is declared elsewhere too ;)).

These are the targets prepended to the Compile target: https://github.com/kzu/GitInfo/blob/master/src/GitInfo/build/GitInfo.targets#L72

You can invoke any of those individually and pass /v:diag to get the detailed output.

Thanks!

[DragonQ]

OK I ran the following command:

"C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe" "Music Folder Syncer.vbproj" /t:GitVersion /v:diag /fl /flp:logfile=MyProjectOutput.log;verbosity=diagnostic

and got this output:

https://gist.github.com/DragonQ/94ebe5edb80f0ae96d91f40a0840fc84

[kzu]

Ha! See the discrepancy there?

  \\hda\Adam\VB Projects\Music Folder Syncer\Project\packages\GitInfo.1.1.20\build\GitInfo.targets(242,4): error MSB4184: The expression "[System.IO.File]::ReadAllText(Y:\VB Projects\Music Folder Syncer\Project\.git\HEAD)" cannot be evaluated. Could not find a part of the path 'Y:\VB Projects\Music Folder Syncer\Project\.git\HEAD'. [\\hda\Adam\VB Projects\Music Folder Syncer\Project\Music Folder Syncer.vbproj]

Y:\ vs \\hda? Is the network share mapped? (I guess so, hence the Y:, but just to be sure).

[DragonQ]

Nope, I have no mapped drives. I access the SMB shares directly (e.g. \hda\Adam...). I think Visual Studio maps SMB shares to drives in a hidden way for some reason - these hidden drives don't appear in This PC, for example, and it'll sometimes be Z: instead of Y: in the log. I believe this is normal behaviour since everything builds fine until I include GitInfo. :/

[kzu]

Plz map the drive and try again? I may just add it as a known issue if
that's what it is...

[DragonQ]

Yes, if I map a drive manually then build from there it works fine. It only fails when accessing via UNC paths, it seems.

[All-the-good-names-were-taken]

Excuse the drive-by comment, but I ran across this, too. I believe your problem is here: https://github.com/kzu/GitInfo/blob/master/src/GitInfo/build/GitInfo.targets#L140. This tries to set the working directory for the git command execution. But you can't set a UNC working directory (you can't cd to a UNC, for example). So msbuild appears to map a drive temporarily, hence the 'z:' or 'y:', then instantly snatches it away.

If git --work-tree behaved sensibly you could have tried that instead. Unfortunately it doesn't. You have to use it with --git-dir, and (again) instead of behaving sensibly it has to match the exact .git dir, not any other subdir of the depot. So you're right back where you started.

I've had the same problem with quite a few msbuild tasks as I regularly build from UNC, so I knew what to look for. I'm afraid I don't know of a way around it except to map the drive. I'd be delighted to be enlightened, though.

[kzu]

Thanks for the in depth information! Such a bummer though :(

[All-the-good-names-were-taken]

Certainly is.

Just had a thought, though. I believe it's possible to map a drive within a build task. In this particular case, that could work. If you could reliably work out if you're given a UNC, perhaps you can create and maintain a mapping for as long as you need it, then clean it up afterwards.

[kzu]

Flagging this so that others can pick it up if they can.

Thanks!

[kzu]

Closing old issues for now.