dotnet
[Feature Request]: Types for file paths and plain text
Summary
In documentation/specs/proposed, security-metadata.md states:
We envision MSBuild to have a first-class-[citizen] type system for [its] data and tasks. 'Secret' would be one of the data types ...
If a type system is introduced, please include a file path type and a plain text type.
Background and Motivation
When a TaskItem is constructed (or ItemSpec is set), the value is passed through FileUtilities.FixFilePath:
https://github.com/dotnet/msbuild/blob/1725b247e8737804076c8ff3b09fcee02ecdf51e/src/Utilities/TaskItem.cs#L75-L81
https://github.com/dotnet/msbuild/blob/1725b247e8737804076c8ff3b09fcee02ecdf51e/src/Utilities/TaskItem.cs#L152-L163
https://github.com/dotnet/msbuild/blob/1725b247e8737804076c8ff3b09fcee02ecdf51e/src/Shared/FileUtilities.cs#L543-L546
FixFilePath makes no change under Windows (where Path.DirectorySeparatorChar will be '\\') but on *NIX OSs (macOS and Linux) a \ character will be replaced with a / character. This makes some sense for file paths but when an Item collection is used for data that is not file paths and that contains \ characters, the data is corrupted.
This issue shows up in multiple places and ways but one example is using the ReadLinesFromFile task to read a JavaScript file that has code using regular expressions. The \ character is an escape character in REs. The same MSBuild project will work correctly on Windows and corrupt the RE expressions on Linux and macOS.
Proposed Feature
- Have a plain text type for values that should not be interpreted.
- Have a file path type that supports making file paths portable/convertible.
- Can be defined with a relative path in either a Windows style or a UNIX style and, when its value is accessed, it tries to default to the current platform.
- It should be possible to explicitly get a UNIX style path under Windows and vice versa.
- Converting fully qualified paths may not be supported.
Alternative Designs
No response
FYI @baronfel
Thank you @jrdodds for a nice suggestion. The strong type system is not yet on the top of MSBuild team priority list (though it's something that was discussed internaly couple times).
