dotnet / msbuild

The Microsoft Build Engine (MSBuild) is the build platform for .NET and Visual Studio.
https://docs.microsoft.com/visualstudio/msbuild/msbuild
MIT License
5.21k stars 1.35k forks source link

Stuck while trying to fix ResolveAssemblyReference tests for Mac/Linux #113

Closed radical closed 9 years ago

radical commented 9 years ago

I am trying to fix the ResolveAssemblyReference tests to work on mac and linux. One of issues is that it has lot of paths like c:\MyLibraries\A.dll, which won't on !Windows. The approach that I have taken for fixing this is to create readonly fields for these paths, and set them accordingly for the the platform. So, on Unix, this would become /MyLibraries/A.dll .

This works fine and I have a PR for the first set of patches ( https://github.com/Microsoft/msbuild/pull/111 ) and more waiting after this (eg. https://github.com/radical/msbuild/tree/rar-new-fields-mycomp )

But I have hit another issue - mixed casing is used for the same path, in different places in the test cases. So, the s_existentFiles may have @"c:\MyLibraries\A.dll" but in other places we have @"c:\MyLibraries\a.DlL" . IIUC, this was not a typo, since there are lot of instances of mismatches like this. So, my question is how should I go about fixing this?

I could simply use Path.Combine(s_myLibrariesRootPath, "a.DlL"), Path.Combine(s_myLibrariesRootPath, "A.dll") etc, and this would be fine for Windows and Mac. But this won't work on Linux. What was the intention with these mismatches? Conditionally using a fixed case path or these variations depending on the platform, sounds messy :/

Suggestions?

ghost commented 9 years ago

Least common denominator: Use the original casing of file path on disk everywhere. That is win-win for everyone. Until the xplat and master are unified (https://github.com/Microsoft/msbuild/issues/64), this is the lifestyle. After the unification, all future tests will need to abide by this convention.

Related: https://github.com/dotnet/corefx/issues/1086

radical commented 9 years ago

Okay, thanks!