Summary

When dotnet new runs the "add project to solution" post-action, it searches for a solution file starting from the output directory and walking up the parent hierarchy. Previously, the search looked for *.sln across the entire ancestor chain first, and only fell back to *.slnx if no .sln was found anywhere. This meant a .slnx in the output directory would be ignored if any .sln existed in an ancestor directory.

Since dotnet new sln now creates .slnx files by default, this caused incorrect behavior: the post-action would target an unrelated .sln in a parent directory instead of the intended local .slnx.

Fix

Changed FindSolutionFilesAtOrAbovePath to search for both .sln and .slnx at each directory level before traversing to the parent, while still preferring .sln over .slnx within the same directory.

Observable difference

The one scenario that changes

A user runs dotnet new <template> in a directory that has a .slnx file, but an ancestor directory also has a .sln file. Previously, the project would be added to the ancestor's .sln. Now it's added to the local .slnx.

A user with a .slnx in their working directory almost certainly intends for the new project to be added there, not to some unrelated .sln higher up the tree. The old behavior was an unintended consequence of the two-pass search approach when .slnx support was added.

Discovery

This was discovered via intermittent CI test failures where a stray .sln file in the Helix temp directory hierarchy was found by the ancestor search, causing the post-action to target a file that was subsequently deleted by another parallel test:

• Build 1466643
• Build 1466026

Test

Added AddProjectToSolutionPostActionPrefersLocalSlnxOverParentSln — a regression test that places a .sln in a parent directory and a .slnx in the output directory, verifying the local .slnx is found.