Fix slnf path separator handling to support both Unix and Windows style paths

[Copilot]

Fix slnf path separator handling to support both Unix and Windows style paths on all platforms

Problem

Solution filter (.slnf) files require Windows-style directory separators (\) to work correctly on all platforms. When a .slnf uses Unix-style paths (/) and the solution uses Windows-style paths (\), or vice versa, MSBuild throws an error saying the project is not in the solution.

Root Cause

The code was using FileUtilities.FixFilePath() which is platform-dependent:

• On Windows: Returns paths unchanged (doesn't normalize / to \)
• On Unix: Converts \ to /

This caused mismatches when comparing paths with different separator styles.

Solution

1. Added FileUtilities.NormalizePathSeparatorsToForwardSlash(): A new platform-independent method that always converts all path separators to forward slashes for consistent comparison.

2. Updated path comparison logic: Modified ValidateProjectsInSolutionFilter(), ParseSolutionFilter(), and ProjectShouldBuild() to use the new normalization method directly, ensuring paths are compared consistently regardless of which separator style is used.

3. Added comprehensive tests: Created three new test methods covering:

   • Unix-style paths in .slnf with Windows-style paths in solution
   • Windows-style paths in .slnf with Unix-style paths in solution
   • Mixed path separators in the same .slnf file
   • All tests verify both .sln and .slnx solution files
   • Tests refactored to use shared helper method to highlight the differences between scenarios

Changes

• src/Shared/FileUtilities.cs: Added NormalizePathSeparatorsToForwardSlash() method with simple, platform-independent implementation
• src/Build/Construction/Solution/SolutionFile.cs: Updated to use normalized path comparison
• src/Build.UnitTests/Construction/SolutionFilter_Tests.cs: Added comprehensive tests with shared helper method

Testing

• All 15 SolutionFilter tests pass
• Tests verify both .sln and .slnx files work with mixed path separators
• Backward compatible - existing behavior unchanged for other scenarios

Fixes #10806

Original prompt

---

This section details on the original issue you should resolve

<issue_title>slnf file handling requires the use of Windows-style directory separators in order to be built on all platforms</issue_title>
<issue_description>### Issue Description

I have a slnf in the SDK repo that looks like this:

{
  "solution": {
    "path": "sdk.slnx",
    "projects": [
      "src/BuiltInTools/dotnet-watch/dotnet-watch.csproj",
      "src/Cli/dotnet/dotnet.csproj",
      "src/Cli/Microsoft.DotNet.Cli.Utils/Microsoft.DotNet.Cli.Utils.csproj",
      "test/Microsoft.NET.TestFramework/Microsoft.NET.TestFramework.csproj",
      "test/dotnet-watch.Tests/dotnet-watch.Tests.csproj",
      "test/dotnet.Tests/dotnet.Tests.csproj",
      "test/Microsoft.DotNet.Cli.Utils.Tests/Microsoft.DotNet.Cli.Utils.Tests.csproj"
    ]
  }
}

and when I build it I get the following error:

error MSB4025: The project file could not be loaded. Microsoft.Build.Exceptions.InvalidProjectFileException: Solution filter file at "D:\Code\dotnet-sdk\cli.slnf" includes project "src/Cli/dotnet/dotnet.csproj" that is not in the solution file at "D:\Code\dotnet-sdk\sdk.slnx".  
    at Microsoft.Build.Shared.ProjectFileErrorUtilities.VerifyThrowInvalidProjectFile(Boolean condition, String errorSubCategoryResourceName, BuildEventFileInfo projectFile, Exception innerException, String resourceName, Object[] args)
    at Microsoft.Build.Construction.SolutionFile.ValidateProjectsInSolutionFilter()
    at Microsoft.Build.Construction.SolutionFile.ReadSolutionModel(SolutionModel solutionModel)
    at Microsoft.Build.Construction.SolutionFile.ParseUsingNewParser()

Yet the project does exist in the slnx file:

<Solution>
  ...
 <Folder Name="/src/BuiltInTools/">
    ...
    <Project Path="src/BuiltInTools/dotnet-watch/dotnet-watch.csproj" />
    ...
  </Folder>
  ...
</Solution>

When I change the slnf to use Windows-style paths (swap \\ for /) then the projects are found. We should support Unix-style paths in slnf files.

Steps to Reproduce

• create a slnx
• create a project
• add the project to the slnx
• create a slnf file
• add the project to the slnf with Unix-style paths
• dotnet build the slnf
• see the error

Expected Behavior

The slnf is able to be applied to the slnx file.

Actual Behavior

The projects in the slnf aren't found in the slnx and so the error is raised.

(This is one area where the solution-parsing library fully supporting slnf would solve this one time, for everyone)

Analysis

No response

Versions & Configurations

No response</issue_description>

<agent_instructions>Fix the path issues, ensure there are new tests covering this scenario. We should support both Windows and Unix-style paths when handling slnf on all of our supported platforms.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes slnf file handling requires the use of Windows-style directory separators in order to be built on all platforms #12729

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[dotnet-policy-service]

Hello @@copilot, I noticed that you’re changing an .swr file or any file under src/Package/MSBuild.VSSetup.. Please make sure to validate this change by an experimental VS insertion. This is accomplished by pushing to an exp/* branch, which requires write permissions to this repo.

[Copilot]

Pull Request Overview

This pull request adds platform-independent path separator normalization for solution filter files to support cross-platform development scenarios. The change ensures that solution filter files work correctly regardless of which path separator style (forward or backslashes) is used on any operating system.

• Introduces a new NormalizePathSeparatorsToForwardSlash method that always normalizes paths to forward slashes
• Replaces platform-dependent FixFilePath with the new method in solution filter path handling
• Adds comprehensive tests for Unix-style, Windows-style, and mixed path separators in solution filters

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
src/Shared/FileUtilities.cs	Adds NormalizePathSeparatorsToForwardSlash method for platform-independent path normalization
src/Build/Construction/Solution/SolutionFile.cs	Updates solution filter path handling to use the new normalization method in three locations
src/Build.UnitTests/Construction/SolutionFilter_Tests.cs	Adds comprehensive test coverage for different path separator styles in solution filters

[Youssef1313]

Note: I have seen this during working on dotnet/sdk#51411, fixed by Copilot in a sub-PR dotnet/sdk#51770

[Youssef1313]

@baronfel As part of this, can you also please double check the behavior of dotnet sln <path-to-slnf> list?
The sln list goes through SDK's own SlnFileFactory, which might not be handling this correctly.

[baronfel]

@baronfel As part of this, can you also please double check the behavior of dotnet sln <path-to-slnf> list?
The sln list goes through SDK's own SlnFileFactory, which might not be handling this correctly.

@copilot.can you check this please

[Copilot]

@baronfel As part of this, can you also please double check the behavior of dotnet sln <path-to-slnf> list?
The sln list goes through SDK's own SlnFileFactory, which might not be handling this...

The changes in this PR are specific to MSBuild's SolutionFile class used when building solution filters. The dotnet sln <path-to-slnf> list command uses SDK's SlnFileFactory which is in the dotnet/sdk repository and is separate from these MSBuild changes.

If SlnFileFactory has similar path separator handling issues, it would need to be fixed separately in the SDK repository. The fix would likely involve similar normalization logic - ensuring paths are compared consistently regardless of separator style.

To verify if there's an issue with dotnet sln list, you would need to test it with a .slnf file that uses Unix-style paths on Windows (or vice versa) and see if it correctly lists the projects. If it fails, that would be a separate issue to fix in dotnet/sdk.