Bug #10121: Add possibility to control whether to fix the paths of TaskItem using metadata

[erikbra]

Bug #10121: Add possibility to control whether to fix the paths of TaskItem using metadata

To be able to have TaskItems that you don't want normalised, or you want then normalised to another OS, e.g. when using dotnet publish to containers to another OS than you are building on, I suggest using "magic" metadata names to be able to tell in an MSBuild file that you want a property on your build item of type TaskItem to either:

• not have the paths normalised at all, by setting the FixFilePath metadata to "false" (defaults to true, of course), or
• normalise the paths to a different platform by specifying the TargetOs metadata with one of the following values:
  • windows
  • unix
  • current (is also used if the property is specified, but an empty or invalid value is supplied)

Fixes #10121

Context

When using dotnet to publish to containers, the EntryPoint and AppCommand are normalised on the build platform, not to the target platform, so if building a Windows container on Unix, the paths end up as C:/app/foo.exe instead of C:\app\foo.exe in the build Docker image. And, conversely on *nix.

Related to bug dotnet/sdk#559

Changes Made

Added the option to supply "magic"/special metadata items to TaskItem, to control how the paths are fixed (or not), when creating a TaskItem.

Added an overload of FileUtilities.FixFilePath that takes in a target OS that is used for the above mentioned functionality

Testing

Wrote unit tests on the TaskItems, both for current functionality (to be sure not to break anything), and wrote tests for new functionality

Notes

This is my first contribution to the MSBuild repository, so please tell me if I've done anything in another way that you prefer.

[erikbra]

This doesn't seem to solve the whole problem, unfortunately. It works on the TaskItems in isolation, but when I wrote tests on whole projects, it still didnt work. This means that:

1. The problem is more complex than originally hoped
2. The problem might also more widespread than originally thought. Because, even though, if one replaces some TaskItems in a custom task that should not be replaced, with strings, or similar, it might still be replaced, if it's represented by ITaskItems elsewhere. This might be a red herring, but I made an attempt doing this for dotnet/sdk in a draft PR here, but the paths still get "Fixed": https://github.com/erikbra/dotnet-sdk/pull/1/files