Normalize directory separator of paths in FileSpec #40699
Conversation
|
Tagging subscribers to this area: @swaroop-sridhar, @agocke |
| { | ||
| SourcePath = sourcePath; | ||
| BundleRelativePath = bundleRelativePath; | ||
| SourcePath = NormalizeDirectorySeparator(sourcePath); |
There was a problem hiding this comment.
Can this be Windows UNC path? If yes, is the normalization going to work well for Windows UNC paths?
There was a problem hiding this comment.
Yes. I think this could break paths like \\x\.... We already normalize relative paths in FileEntry, I made the change there, more economic/safe.
|
I wonder if it would instead make sense to instead do the normalization in the SDK at https://github.com/dotnet/sdk/blob/750e56eaa044ba730be3fc39fc715e6bef38eeb7/src/Tasks/Microsoft.NET.Build.Tasks/GenerateBundle.cs#L54? That way HostModel would not need to work around the inconsistent and platform-unaware path representation by MSBuild, and it could in theory be used with filenames containing |
| { | ||
| Type = fileType; | ||
| RelativePath = relativePath.Replace(Path.DirectorySeparatorChar, DirectorySeparatorChar); | ||
| RelativePath = relativePath.Replace('\\', DirectorySeparatorChar); |
There was a problem hiding this comment.
Won't this break if this is a unix path that actually has a \ in the file name?
There was a problem hiding this comment.
It would, but I'm not sure what the experience should be for these cases... dotnet new console -o 'a\b\c' or having a C# file named 'x\y\z.cs' and then doing dotnet build won't work either.
There was a problem hiding this comment.
You're right -- it looks like the rest of the tooling doesn't like that either. In that case, I'm fine with this fix. The scenario we'd be breaking really isn't supported today.
|
I think the technically correct solution would be to use a |
|
Sure, but if we try to fix it downstream, how can we tell the difference between a |
|
Any way to test this in the runtime repo? |
Yes, but first we need this change to be available in the SDK. We basically have to run the tests that we already have in |
ghost
locked as resolved and limited conversation to collaborators
6 participants
The SDK uses a backslash as a directory separator for copied satellite assemblies, which causes trouble when generating a single file bundle in Unix, where it's completely valid to use
\in filenames, thus erroneously embedding these files as 'en-US\Something.resource.dll'.