Search for slnx files when setting solution-relative content root

[kimsey0]

Search for slnx files when setting solution-relative content root

• You've read the Contributor Guide and Code of Conduct.
• You've included unit or integration tests for your change, where applicable.
• You've included inline docs for your change, where applicable.
• There's an open issue for the PR that you are making. If you'd like to propose a new feature or change, please open an issue to discuss the change or find an existing issue.

Fixes #61304

[kimsey0]

I think this implementation is both source and binary backwards compatible (except for the semantic change of now looking for slnx files too), but would like someone to verify that.

For already compiled assemblies:

• Calls to builder.UseSolutionRelativeContentRoot(string solutionRelativePath, string solutionName = ".sln") now go to builder.UseSolutionRelativeContentRoot(string solutionRelativePath, string solutionName) and keep the old behavior.
• Calls to builder.UseSolutionRelativeContentRoot(string solutionRelativePath, string applicationBasePath, string solutionName = ".sln") now to builder.UseSolutionRelativeContentRoot(string solutionRelativePath, string applicationBasePath, string solutionName) and keep the old behavior.

For recompiled assemblies:

• Calls to builder.UseSolutionRelativeContentRoot(string solutionRelativePath, string solutionName = ".sln") that omit the optional parameter now go to builder.UseSolutionRelativeContentRoot(string solutionRelativePath) and get the new support for .slnx files.
• Calls to builder.UseSolutionRelativeContentRoot(string solutionRelativePath, string applicationBasePath, string solutionName = ".sln") that omit the optional parameter (by passing applicationBasePath as a named parameter) now go to builder.UseSolutionRelativeContentRoot(string solutionRelativePath, string applicationBasePath, ReadOnlySpan<string> solutionNames = default) and get the new support for .slnx files.

[kimsey0]

Tests are failing for two reasons:

1. I put the new changes in PublicAPI.Shipped.txt. I'm not sure if this should be in ASP.NET Core 9 or 10, thus Shipped or Unshipped? (Or am I misunderstanding something?)
2. UseSolutionRelativeContentRoot doesn't currently handle permission errors while climbing the folder hierarchy. I think it would make sense to just have it stop if it encounters an UnauthorizedAccessException, but that is technically an unrelated change. Is it fine to add here?

[Copilot]

Pull Request Overview

This PR adds support for searching .slnx files (XML-based solution files) when setting solution-relative content roots in the TestHost library. The functionality extends the existing UseSolutionRelativeContentRoot methods to support both traditional .sln and newer .slnx solution files by default.

Key changes:

• Updated the UseSolutionRelativeContentRoot method to search for both .sln and .slnx files by default
• Refactored the API to accept multiple solution file patterns via ReadOnlySpan
• Added comprehensive test coverage for .slnx file support

Reviewed Changes

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

File	Description
WebHostBuilderExtensions.cs	Modified UseSolutionRelativeContentRoot methods to support multiple solution file patterns and added .slnx support
PublicAPI.Shipped.txt	Updated public API surface to reflect the new method signatures
UseSolutionRelativeContentRootTests.cs	Added comprehensive test coverage for .slnx file detection and multiple solution file scenarios
WebApplicationFactorySlnxTests.cs	Added integration tests verifying .slnx support works with WebApplicationFactory

[slang25]

@danroth27 not sure if this is on the roadmap for aspnetcore 10, but it would be great to get in and allow easy migration of sln → slnx.

Even though this is a feature independent from dotnet and aspnetcore, I predict a lot of folks will adopt this around the .NET 10 time frame, so having the migration work seamlessly will be valuable to many customers.

[danmoseley]

@halter73 do you have cycles to review this? slnx support does seem valuable for .NET 10

[halter73]

Thanks for the PR! Can you please open an API Proposal issue for this change? Thanks again.

[kimsey0]

I just came back from a long vacation. Thanks for carrying this to completion, @slang25 and @halter73. Cheers!

[bkoelman]

Could this change be backported to .NET 8 and 9? Our project (and tests) multi-target 8/9/10, and we're running into the same limitation as described at #61304 (comment) (we have Startup classes in different assemblies).

Without backports, we can't update to slnx until those frameworks are EOL. Unless we try the hack described at #61304 (comment).

[wtgodbe]

Could this change be backported to .NET 8 and 9?

Unfortunately we can't make API breaking changes in servicing releases. Is the workaround you linked not sufficient?

[halter73]

We could consider taking just the behavioral change without the API change. @kimsey0 notes in #61304 (comment) that the .NET 10 change is technically also behaviorally breaking if you have a .slnx file that then shadows a .sln file in a parent folder. But even that can be avoided if we added a test-only, last-ditch fallback to "*.slnx" only if we would otherwise throw an InvalidOperationException for not having found a ".sln" file.

Given the high demand for this, and that we can limit the behavioral change to test projects when an InvalidOperationException would have otherwise been thrown, I think we probably should backport a fix to .NET and .NET 8. I had a Copilot create a PR for release/9.0 at https://github.com/dotnet/aspnetcore/pull/64953/changes that has the limited fix. What do you think @wtgodbe?

[bkoelman]

@wtgodbe What I meant to suggest is to backport the behavior change without the API change, as clarified by @halter73. Our only options today are to wait until .NET 9 EOL, or move away from WebApplicationFactory entirety, which affects the majority of 19,000 tests.

[halter73]

Our only options today are to wait until .NET 9 EOL, or move away from WebApplicationFactory entirety, which affects the majority of 19,000 tests.

@bkoelman I personally in favor of the backport just to avoid people running into unnexpecged issues when updating .NET 8 and 9 project to use slnx, but couldn't you update your tests to call something like the following?

builder.UseSolutionRelativeContentRoot(typeof(TEntryPoint).Assembly.GetName().Name!, AppContext.BaseDirectory, "*.slnx");

[bkoelman]

Our only options today are to wait until .NET 9 EOL, or move away from WebApplicationFactory entirety, which affects the majority of 19,000 tests.

@bkoelman I personally in favor of the backport just to avoid people running into unnexpecged issues when updating .NET 8 and 9 project to use slnx, but couldn't you update your tests to call something like the following?

builder.UseSolutionRelativeContentRoot(typeof(TEntryPoint).Assembly.GetName().Name!, AppContext.BaseDirectory, "*.slnx");

No, that doesn't work because UseSolutionRelativeContentRoot is called internally (resulting in a crash) before we get a chance to call it ourselves.

[bkoelman]

Thanks a lot for the packports!