Fix dotnet run to accept Windows path separators on Linux

[Copilot]

The dotnet run command fails on Linux when provided with Windows-style path separators (backslashes), breaking cross-platform PowerShell scripts and mixed development environments.

Problem

After PR #49544 added file existence validation, the following command fails on Linux:

dotnet run --project .\src\MyProject\MyProject.csproj

With error:

The provided file path does not exist: .\src\MyProject\MyProject.csproj.

While the equivalent with forward slashes works correctly:

dotnet run --project ./src/MyProject/MyProject.csproj

This regression breaks PowerShell scripts that use Windows-style paths and expect them to work cross-platform.

Solution

Added path separator normalization in RunCommand.DiscoverProjectFilePath() to convert Windows-style backslashes to forward slashes on non-Windows platforms before checking file existence:

// Normalize path separators to handle Windows-style paths on non-Windows platforms
if (Path.DirectorySeparatorChar != '\\')
{
    projectFileOrDirectoryPath = projectFileOrDirectoryPath.Replace('\\', '/');
}

Testing

• Added platform-specific unit tests for both Windows and Linux path handling
• Verified that .\src\MyProject\MyProject.csproj correctly normalizes to ./src/MyProject/MyProject.csproj on Linux
• Confirmed no regression on Windows (backslashes continue to work natively)
• All existing tests continue to pass

The fix is minimal, platform-aware, and preserves all existing behavior while enabling cross-platform compatibility for Windows-style paths.

Fixes #50828.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[Youssef1313]

This regression breaks PowerShell scripts that use Windows-style paths and expect them to work cross-platform.

@baronfel @jjonescz @marcpopMSFT Is this expectation really correct? I was expecting this should actually fail (in my view, both separators should work on Windows, but only / should work for Unix)? Do we need to do any equivalent changes for dotnet test?

[jjonescz]

It is a regression, so that might be a good reason to continue supporting it. (I personally don't mind if we break this either.) Otherwise I agree that it's fine when \ does not work on Linux.

[jjonescz]

Consider adding a comment that we only support this for historical reasons to avoid a break. We probably don't strive to support \ on Linux in all path arguments.

[Youssef1313]

In that case yeah let's not support that in dotnet test.
A comment would help.

[Youssef1313]

FYI, this targets main. And Copilot PRs don't seem to get the automatic comment about the branch.

[marcpopMSFT]

A regression from a preview feature is hard to balance if we should keep this. The feedback came from a customer using the feature though. @baronfel as this is a bit of a business decision as to whether it's better to error as expected or accept this for better compat.

[baronfel]

I'm mostly wondering three things:

• is there a BCL API that can normalize this for us
• can we systematize this so that we auto-normalize wherever we need?
• are there other places where we're vulnerable to this?

[akoeplinger]

Backslash is a valid filename character on Unix so this would break that case. I don't think we should be in the business of normalizing paths in the CLI. hmm I just tested and e.g. dotnet build some\folder\app.csproj works and from the original issue it worked in net9 for run too so maybe there are more users that would hit it