Add support for Solution Filters (.slnf)

[baronfel]

Currently the .NET SDK, DevKit, and other tools that want to interact with solutions correctly have to manually implement for Solution Filter files.

• .NET SDK (via dotnet test):
  • there are other places where we need to add support aside from this
• ionide/proj-info (F# tooling/VSCode)
• DevKit
• MSBuild

And surely more! This is a common tooling scenario that would benefit from a centralized implementation - in addition many of these existing parsers parse the solution in a very inefficient way: they load the entire solution and then apply the mask from the filter to the loaded solution. In an ideal world, the filter could be applied during solution parsing to limit the total amount of work done.

[jasonmalinowski]

Another one in Roslyn: https://github.com/dotnet/roslyn/blob/b23154fe97826599cf486ce0159ec8e981381366/src/Workspaces/MSBuild/Core/MSBuild/MSBuildProjectLoader.SolutionFilterReader.cs#L23

[svew]

Please do not require filtering to exist in a separate file, filtering should be possible within the solution file as well.

[PadreSVK]

@baronfel @svew What are your thoughts about the proposed #111?

[svew]

@baronfel @svew What are your thoughts about the proposed #111?

Personally, and from the perspective of my team's workflow, I don't think #111 would likely solve any problems our team has.

We have over 1000 MSBuild projects, and dozens of solution files that are not well maintained. The benefit we would see from simplified solution files would be the ease of generating those solution files automatically, so we don't have to put in extra work to maintain them. In this situation, project files are our one source of truth, solution files are just a tool to show a group projects in VS, and filters are a way to not load 200 projects all at once when opening up the solution for a project with many dependencies.

We'd benefit more from solution files being able to read and apply project metadata from project files directly rather than solutions supplying their own project metadata.

[thompson-tomo]

For me the solution would be a combination of #111 to enable Grouping of projects into collections & #116 to enable a slnx to behave just like we have with Directory.build.props & directory.packages.props. With that importing process slnx can replace slnf and we just have 1 definition of solutions.