Repository navigation
Honor .slnf solution filters when reading the solution's project set - #422
Merged
Merged
Conversation
razzmatazz
approved these changes
Sep 3, 2026
solutionLoadProjectFilenames read ProjectsInOrder from SolutionFile.Parse, which for a .slnf lists every project of the PARENT solution. Two visible effects on filtered solutions: the load-progress denominator counted the whole parent solution (dotnet/roslyn Compilers.slnf reported "(74/358)" and finished with the percentage stuck at 20), and the workspace-global TargetFramework intersection ran over projects the filter excludes, which can wrongly disengage the multi-tfm support. MSBuild applies the filter internally but exposes no public way to query it, so SolutionFile.ProjectShouldBuild is resolved by reflection, the way this server already reaches Roslyn internals. Reusing MSBuild's own predicate also keeps the match correct: it normalizes path separators and then compares with a comparer that is case-sensitive on Linux and case-insensitive everywhere else. The predicate answers true for every project when the solution carries no filter, so it needs no .slnf check of its own. Microsoft.Build is whichever assembly MSBuildLocator found in the installed SDK rather than a pinned package reference, so a member that stops existing logs a warning and degrades to loading every declared project instead of failing the solution load. Test-side: a solutionWithFilter fixture (three-project Full.sln plus a Partial.slnf keeping two) loaded through solutionPathOverride; before the fix the progress reports read "(1/3)", "(2/3)" and stopped at 66. The test harness now copies .slnf files into the temp fixture dir, and the progress-report collection shared by the load-progress tests moved into a helper.
pbednarcik
force-pushed
the
fix/slnf-project-count
branch
from
September 3, 2026 07:35
7827fd0 to
d2353d0
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
solutionLoadProjectFilenamesreadsProjectsInOrderfromSolutionFile.Parse, and for a.slnfthat lists every project of the parent solution, not the filtered set. MSBuild applies the filter internally when building, but the project set we derive from it is wrong, with two visible effects on a filtered solution:Compilers.slnfthe reports read(74/358)and the percentage stopped at 20 (this is the counter from feat: report per-project progress while loading a solution #417, so the bug is mine to fix)TargetFrameworkintersection runs over projects the filter excludes, which can disengage the multi-TFM support for no reasonSolutionFile.ProjectShouldBuildanswers exactly this question but it is internal, so it is resolved by reflection, the way this server already reaches Roslyn internals. It answers true for every project when the solution carries no filter, so it needs no.slnfcheck of its own.Microsoft.Buildcomes from the SDK that MSBuildLocator picked rather than from a pinned package reference, so a member that stops existing logs a warning and degrades to loading every declared project instead of failing the solution load.Test: a new
solutionWithFilterfixture (three-projectFull.sln,Partial.slnfkeeping two of them) loaded throughsolutionPathOverride. Before the fix the progress reports readProjectA (1/3),ProjectC (2/3)and stopped at 66; with the fix they read(1/2),(2/2)and reach 100. The test harness did not copy.slnffiles into the temp fixture dir, so that is added to the copy filter, and the progress-report collection shared by the load-progress tests moved into a small helper.