Search for slnx files when setting solution-relative content root #61305

kimsey0 · 2025-04-03T12:53:07Z

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.

src/Hosting/TestHost/src/WebHostBuilderExtensions.cs

…y default

kimsey0 · 2025-07-18T22:05:02Z

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 · 2025-07-18T22:22:32Z

Tests are failing for two reasons:

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?)
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

src/Hosting/TestHost/src/WebHostBuilderExtensions.cs

kimsey0 · 2025-07-18T23:32:20Z

src/Hosting/TestHost/src/WebHostBuilderExtensions.cs

+        this IWebHostBuilder builder,
+        string solutionRelativePath,
+        string applicationBasePath,
+        ReadOnlySpan<string> solutionNames = default)


Should this use IReadOnlyCollection<string> or similar instead? It's not exactly performance sensitive.

I think ReadOnlySpan<string> is fine, but we can discuss this in the API proposal issue.

kimsey0 · 2025-07-18T23:36:27Z

src/Hosting/TestHost/src/WebHostBuilderExtensions.cs

        var directoryInfo = new DirectoryInfo(applicationBasePath);
        do
        {
-            var solutionPath = Directory.EnumerateFiles(directoryInfo.FullName, solutionName).FirstOrDefault();
-            if (solutionPath != null)
+            foreach (var solutionName in solutionNames)


This could be a LINQ query instead if you prefer.

I think the foreach is fine.

slang25 · 2025-07-21T10:30:44Z

@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 · 2025-07-21T21:12:37Z

@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.

halter73 · 2025-07-29T16:32:55Z

src/Hosting/TestHost/src/PublicAPI.Shipped.txt

+static Microsoft.AspNetCore.TestHost.WebHostBuilderExtensions.UseSolutionRelativeContentRoot(this Microsoft.AspNetCore.Hosting.IWebHostBuilder! builder, string! solutionRelativePath) -> Microsoft.AspNetCore.Hosting.IWebHostBuilder!
+static Microsoft.AspNetCore.TestHost.WebHostBuilderExtensions.UseSolutionRelativeContentRoot(this Microsoft.AspNetCore.Hosting.IWebHostBuilder! builder, string! solutionRelativePath, string! applicationBasePath, string! solutionName) -> Microsoft.AspNetCore.Hosting.IWebHostBuilder!
+static Microsoft.AspNetCore.TestHost.WebHostBuilderExtensions.UseSolutionRelativeContentRoot(this Microsoft.AspNetCore.Hosting.IWebHostBuilder! builder, string! solutionRelativePath, string! applicationBasePath, System.ReadOnlySpan<string!> solutionNames = default(System.ReadOnlySpan<string!>)) -> Microsoft.AspNetCore.Hosting.IWebHostBuilder!
+static Microsoft.AspNetCore.TestHost.WebHostBuilderExtensions.UseSolutionRelativeContentRoot(this Microsoft.AspNetCore.Hosting.IWebHostBuilder! builder, string! solutionRelativePath, string! solutionName) -> Microsoft.AspNetCore.Hosting.IWebHostBuilder!


These changes should go in the PublicAPI.Unshipped.txt file. For the cases where you removed the default value for the optional solutionName parameter, you can prefix the old API with *REMOVED* and then re-add it without the default value. You can take a look at the OpenApi PublicAPI.Unshipped.txt for reference.

halter73 · 2025-07-29T16:36:15Z

src/Hosting/TestHost/src/WebHostBuilderExtensions.cs

@@ -144,19 +158,45 @@ public static IWebHostBuilder UseSolutionRelativeContentRoot(
        this IWebHostBuilder builder,
        string solutionRelativePath,
        string applicationBasePath,
-        string solutionName = "*.sln")
+        string solutionName)


Nit: I think we can remove the [SuppressMessage(... from this overload now too.

It's really unfortunate that we have all these overloads of just string parameters and we decided to add applicationBasePath to the middle of the parameter list instead of the end. That's what RS0026 was warning about. It makes it very difficult to make backwards compatible changes, but I think this change is safe. I'm glad the new overload at least takes a type other than string.

halter73 · 2025-07-29T16:36:44Z

src/Hosting/TestHost/src/WebHostBuilderExtensions.cs

+    /// <param name="applicationBasePath">The root of the app's directory.</param>
+    /// <param name="solutionNames">The names of the solution files to make the content root relative to. If empty, defaults to *.sln and *.slnx.</param>
+    /// <returns>The <see cref="IWebHostBuilder"/>.</returns>
+    [SuppressMessage("ApiDesign", "RS0026:Do not add multiple public overloads with optional parameters", Justification = "Required to maintain compatibility")]


Suggested change

[SuppressMessage("ApiDesign", "RS0026:Do not add multiple public overloads with optional parameters", Justification = "Required to maintain compatibility")]

Is this still necessary considering it's now the only overload of UseSolutionRelativeContentRoot that has a default parameter?

halter73 · 2025-07-29T16:37:05Z

src/Hosting/TestHost/src/WebHostBuilderExtensions.cs

+        this IWebHostBuilder builder,
+        string solutionRelativePath,
+        string applicationBasePath,
+        ReadOnlySpan<string> solutionNames = default)


I think ReadOnlySpan<string> is fine, but we can discuss this in the API proposal issue.

halter73 · 2025-07-29T16:37:28Z

src/Hosting/TestHost/src/WebHostBuilderExtensions.cs

        var directoryInfo = new DirectoryInfo(applicationBasePath);
        do
        {
-            var solutionPath = Directory.EnumerateFiles(directoryInfo.FullName, solutionName).FirstOrDefault();
-            if (solutionPath != null)
+            foreach (var solutionName in solutionNames)


I think the foreach is fine.

ghost added the area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions label Apr 3, 2025

dotnet-policy-service bot added the community-contribution Indicates that the PR has been added by a community member label Apr 3, 2025

kimsey0 mentioned this pull request Apr 3, 2025

WebApplicationFactory doesn't set solution relative content root if you switch to slnx solution #61304

Open

1 task

kimsey0 commented Apr 3, 2025

View reviewed changes

src/Hosting/TestHost/src/WebHostBuilderExtensions.cs Outdated Show resolved Hide resolved

kimsey0 force-pushed the patch-1 branch 3 times, most recently from 9478bcc to c4ac2d6 Compare July 18, 2025 16:56

build-analysis bot mentioned this pull request Jul 18, 2025

Known Build Error: error : Cannot create a file when that file already exists. #61178

Open

Update UseSolutionRelativeContentRoot to support sln and slnx files b…

cfcc236

…y default

kimsey0 force-pushed the patch-1 branch from c4ac2d6 to cfcc236 Compare July 18, 2025 18:24

kimsey0 marked this pull request as ready for review July 18, 2025 22:22

Copilot AI review requested due to automatic review settings July 18, 2025 22:22

kimsey0 requested review from tdykstra, a team and halter73 as code owners July 18, 2025 22:22

Copilot AI reviewed Jul 18, 2025

View reviewed changes

src/Hosting/TestHost/src/WebHostBuilderExtensions.cs Show resolved Hide resolved

src/Hosting/TestHost/src/WebHostBuilderExtensions.cs Show resolved Hide resolved

kimsey0 commented Jul 18, 2025

View reviewed changes

dotnet-policy-service bot added the pending-ci-rerun When assigned to a PR indicates that the CI checks should be rerun label Jul 29, 2025

kimsey0 closed this Jul 29, 2025

kimsey0 reopened this Jul 29, 2025

dotnet-policy-service bot added this to the 10.0-rc1 milestone Jul 29, 2025

halter73 reviewed Jul 29, 2025

View reviewed changes

Search for slnx files when setting solution-relative content root #61305

Are you sure you want to change the base?

Search for slnx files when setting solution-relative content root #61305

Conversation

kimsey0 commented Apr 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

kimsey0 commented Jul 18, 2025

Uh oh!

kimsey0 commented Jul 18, 2025

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

slang25 commented Jul 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

danmoseley commented Jul 21, 2025

Uh oh!

halter73 left a comment

Choose a reason for hiding this comment

Uh oh!

halter73 Jul 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

kimsey0 commented Apr 3, 2025 •

edited

Loading

slang25 commented Jul 21, 2025 •

edited

Loading

halter73 Jul 29, 2025 •

edited

Loading