-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Search for slnx files when setting solution-relative content root #61305
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
9478bcc to
c4ac2d6
Compare
|
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:
For recompiled assemblies:
|
|
Tests are failing for two reasons:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
|
@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. |
|
@halter73 do you have cycles to review this? slnx support does seem valuable for .NET 10 |
halter73
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR! Can you please open an API Proposal issue for this change? Thanks again.
* Avoid race that can cause Kestrel's RequestAborted to not fire (#62385) * Send Keep-Alive Ping Immediately When Previous Ping Is Overdue (#63195) * Make new validations consistent with System.ComponentModel.DataAnnotations behavior (#63231) * Add support for type-level validation attributes, update validation ordering * Code review fix, test fix * Fix trimming annotation * Fix trimming annotation * Separate caches for property and type attributes * Fix typo Co-authored-by: Brennan <[email protected]> * Fix typo Co-authored-by: Brennan <[email protected]> * Fix and simplify the emitted code * Update src/Validation/test/Microsoft.Extensions.Validation.GeneratorTests/ValidationsGeneratorTestBase.cs --------- Co-authored-by: Brennan <[email protected]> Co-authored-by: Safia Abdalla <[email protected]> * Search for slnx files when setting solution-relative content root (#61305) * Address API review feedback for what was IApiEndpointMetadata (#63283) --------- Co-authored-by: Stephen Halter <[email protected]> Co-authored-by: Reagan Yuan <[email protected]> Co-authored-by: Ondřej Roztočil <[email protected]> Co-authored-by: Brennan <[email protected]> Co-authored-by: Safia Abdalla <[email protected]> Co-authored-by: Jacob Bundgaard <[email protected]>
|
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). |
Unfortunately we can't make API breaking changes in servicing releases. Is the workaround you linked not sufficient? |
|
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 |
@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 |
Search for slnx files when setting solution-relative content root
Fixes #61304