maybe: show better error msg if windows visual studio git outputs linux paths

[binary1230]

So, ultimately, I think this is a PATH misconfiguration problem on my end, and fixing it has fixed my issue with GitInfo.

I'm running windows 10 + GitInfo latest 2.1.2, visual studio 2019 community edition.

I installed via Nuget and got a cascade of weird errors (like not being able to find the 'System' namespace)

My .sln file was in a directory, let's call it D:\projects\project1\

The clue was this error message here:

Severity	Code	Description	Project	File	Line	Suppression State
Error		The specified task executable "cmd.exe" could not be run. System.IO.DirectoryNotFoundException: The working directory "D:\d\projects\project1\" does not exist.
   at Microsoft.Build.Tasks.Exec.GetWorkingDirectory()
   at Microsoft.Build.Utilities.ToolTask.GetProcessStartInfo(String pathToTool, String commandLineCommands, String responseFileSwitch)
   at Microsoft.Build.Utilities.ToolTask.ExecuteTool(String pathToTool, String responseFileCommands, String commandLineCommands)
   at Microsoft.Build.Tasks.Exec.ExecuteTool(String pathToTool, String responseFileCommands, String commandLineCommands)
   at Microsoft.Build.Utilities.ToolTask.Execute()	

The path is incorrect. Should be:
"D:\projects\project1\"
Instead, it's:
"D:\d\projects\project1\"

In the script, gitinfo uses git rev-parse --show-toplevel to get the path. If I run the visual studio version of git, I get this correct output:

"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\Git\mingw32\bin\git.exe" rev-parse --show-toplevel

gives correct output of:
"D:\projects\project1\"

But what was happening was I had mingw64 version of git.exe (likely... incorrectly) in my path, and it was returning the unix-style path:
git rev-parse --show-toplevel output was /d/projects/project1

Somewhere in GitInfo it was attempt to marry /d/project/project1 and D:\ and produced an incorrect path of:
"D:\d\projects\project1\"

Then it all failed. Fixing my path fixed the issue and now everything's fine.

---

I don't know if this bug is worth trying to figure out, or if it's better to say 'silly user, please fix your busted path'.

Either way, it might be nice to at least detect the condition and either convert to a windows-style path.

Or at least display some kind of error message to give a hint about what to fix. Something like "We detected your version of git using unix-style paths, we need you to fix your PATH so it has a windows-like path".

You could do it by looking for patterns like:

"{someuppercaseletter}:\{thesamebutlowercaseletter}\" to catch strings that look like this: "D:\d\[whatever]"

Anyway, otherwise the plugin looks awesome, was just a little confused tracking down the issue as a first time user.

Thanks!
-Dom

[kzu]

Oh, wow, you definitely went down the rabbit hole with this one! :(

Yeah, I think the targets could check that the path separator matches the detected OS. Might not be trivial to do it in all relevant places.

Maybe you could take a shot at sending a PR?

Thanks in advance, I'll keep it open as an enhancement in case someone from the community wants to take a shot at it.

[binary1230]

Ksu, if I have time, I'll give a pull request a shot that at least drops a breadcrumb pointing to the solution if a user hits this issue

Totally unrelated to this issue: I just realized I think I was using your ObservableDictionary gist in a project I was messing around with recently. Small world :)

[kzu]

Haha, awesome!! 😍

[kzu]

I was just reviewing old issues, and it occurred to me that perhaps another fix would be to add another target before SetGitExe that basically sets it to the VS-provided one if it's found, whenever you're building from within VS (by checking BuildingInsideVisualStudio=true...