Add NormalizePath() to IntrinsicFunctions

[jeffkl]

Rather than just "fix" the file path, this normalizes it and fixes the directory separators. I did not make a unit test because FileUtilities.NormalizePath() is well tested.

Closes #55

[danmoseley]

FileUtilities.NormalizePath() can throw, what happens when use in a project file causes an exception?

[jeffkl]

Excellent question. If you pass it an empty string, you get an error during your build:

Microsoft (R) Build Engine version 15.1.418.63065
Copyright (C) Microsoft Corporation. All rights reserved.

Build started 11/30/2016 8:10:23 AM.
Project "C:\Users\jeffkl\Desktop\55.proj" on node 1 (default targets).
C:\Users\jeffkl\Desktop\55.proj(11,14): error MSB4184: The expression "[MSBuild]::NormalizePath(*<>)" cannot be evaluated. Illegal characters in path.
Done Building Project "C:\Users\jeffkl\Desktop\55.proj" (default targets) -- FAILED.


Build FAILED.

"C:\Users\jeffkl\Desktop\55.proj" (default target) (1) ->
(Build target) ->
  C:\Users\jeffkl\Desktop\55.proj(11,14): error MSB4184: The expression "[MSBuild]::NormalizePath('')" cannot be evaluated. Parameter "path" cannot have zero length.

    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:00.26

If you have invalid characters you get this:

error MSB4184: The expression "[MSBuild]::NormalizePath(*<>)" cannot be evaluated. Illegal characters in path.

Invalid UNC path:

error MSB4184: The expression "[MSBuild]::NormalizePath(\\??\\)" cannot be evaluated. The UNC path should be of the form \\server\share.

Long path:

error MSB4184: The expression "[MSBuild]::NormalizePath(12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890)" cannot be evaluated. The specified path, file name, or both are too long.
 The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.

Do the errors seem like they are a good user experience?

[rainersigwald]

@jeffkl put a non-digit character in there--we may be trying to coerce it to an int or something?

[jeffkl]

Okay I fixed the PathTooLongException message so now it says:

error MSB4184: The expression "[MSBuild]::NormalizePath(12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890)" cannot be evaluated. The specified path, file name, or both are too long.
 The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.

[jeffkl]

@rainersigwald

put a non-digit character in there--we may be trying to coerce it to an int or something?

A number doesn't appear to matter:

<Message Text="Result: '$([MSBuild]::NormalizePath(123))'" />

  Result: 'C:\Users\jeffkl\Desktop\123'

Anything else I should try?

[jeffkl]

@AArnott hate to bother you, do you know why GitVersioning would crash like this?
https://ci2.dot.net/job/Microsoft_msbuild/job/master/job/_Windows_NT_Desktop_prtest/95/consoleFull#153167369479494335-f7bd-47d0-8771-8661e00c2db2

It only happens in our CI environment and I can't get it to repro locally. Before I spent any time looking into it I figured I'd ping you just in case you knew what the problem is or where to start.

[rainersigwald]

@jeffkl I filed #1409 since in my feature branch I just disabled it. Would really like to get to the bottom of it, though.

[AArnott]

@jeffkl: my best guess, since the failure is deep within libgit2sharp in reading a tree object, is that the git commit is corrupted/invalid, or that the server didn't initialize the .git directory correctly.
My first suggestion is to try to build again on a clean agent (that has no prior git clone).
My second suggestion is run git fsck on a clone with that commit in it to see if it's invalid somehow.

[jeffkl]

@AArnott thanks a lot, I'll see what I can figure out.

[jeffkl]

@AArnott I was able to figure out that our CI build definition changed recently to do a shallow clone and so GitVersioning obviously wouldn't be able to calculate commit height. I changed the setting back in the build definition and everything is working again. Just a heads up in case anyone else hits the issue. Thanks again for pointing me in a direction.

[jeffkl]

@dotnet-bot test Windows_NT Build for Desktop please

[jeffkl]

I decided to add a NormalizeDirectory() as well which can be used to combine, normalize, and ensure a trailing slash. Passing in an empty directory will return String.Empty rather than throwing an error.

[AArnott]

@jeffkl Thanks for letting me know what it was. NB.GV does document that shallow cloning isn't supported, but it would be interesting for me to test this further so that instead of a strange failure like this it could give a more helpful message to reduce time like yours spent investigating. I've filed dotnet/Nerdbank.GitVersioning#92 to track.