Handle unsupported paths in ProjectInSolution.AbsolutePath

[jeffkl]

Fixes #6236

Context

#5950 introduced a call to Path.GetFullPath() to get a path that is normalized. However, in some cases Visual Studio stores unsupported paths which will cause Path.GetFullPath() to throw.

Path.GetFullPath() can also throw a PathTooLongException which is now handled.

Changes Made

Revert to legacy code path of just calling Path.Combine() then do the Path.GetFullPath() in a try...catch on a best effort.

Testing

Regression test added

Notes

https://developercommunity.visualstudio.com/t/msbuild-failing-with-web-site-project-in/1359528

[benvillalobos]

Copy/pasting my comment from the issue:

@jeffkl looking at dates for 16.9 servicing releases. Looks like final sign off for 16.9.2 is in five days, and sign off for 16.9.3 is 4/12.
I'm open to either bringing in the quick fix before 16.9.2 and then implementing the long-term solution.
Or going straight for the long term solution.

If this code path really doesn't get hit much during builds (particularly web builds), I'm open to just catching the exception and leaving it at that.

[benvillalobos]

Whatever we decide, this should target vs16.9 and flow back into master

[benvillalobos]

LGTM

[Forgind]

Looks mostly good!

[Forgind]

Could we add a simpler path normalization here like (look for \..\) -> remove along with the prior path segment?

[jeffkl]

I'd hate to get the logic wrong, I think the new code is pretty good to handle the situation more correctly.

[jeffkl]

Wow that's interesting, on .NET Core Path.GetFullPath() doesn't throw, it just mangles the URL

Path.GetFullPath(@"C:\Users\jeffkl\AppData\Local\Temp\srl1rctk.qyt\http://localhost:8080")
C:\Users\jeffkl\AppData\Local\Temp\srl1rctk.qyt\http:\localhost:8080

I'll have to call Uri.TryCreate()...

[Forgind]

LGTM! Thanks!