Use slnx files instead of sln per library node

[ViktorHofer]

EDIT: Renamed to move to slnx, a new solution file format coming with a future version of VS.

We currently use slns per library but should investigate using slnfs instead. Example for System.Runtime: https://github.com/dotnet/runtime/blob/main/src/libraries/System.Runtime/System.Runtime.sln

By using an slnf, developers are able to update the solution files more easily and the files are less complex (less merge conflicts).

This is currently blocked on #93877

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

---

We currently use slns per library but should investigate using slnfs instead. Example for System.Runtime: https://github.com/dotnet/runtime/blob/main/src/libraries/System.Runtime/System.Runtime.sln

By using an slnf, developers are able to update the solution files more easily and the files are less complex (less merge conflicts).

This is currently blocked on #93877

Author:	ViktorHofer
Assignees:	-
Labels:	area-Infrastructure-libraries
Milestone:	-

[lsoft]

We are using 1 sln + many children slnfs for 2 years now. Let me share some feedback.

The situation a single sln file + a lot of slnf files is better than a lot of sln files, but not too much. Merging is easier, yes. But you can easily find yourselves in situation you need to add a new csproj into many slnf files, and this is not very different from adding new csproj to many sln files.

I posted an issue about this difficulty to Dev Community 2 years ago about automation... nothing happened, of course. So, my hope is that the things will start moving forward when runtime repo switched to slnf files :)

[huoyaoyuan]

Note that VS support of slnf is somehow suboptimal. When sln is changed in some Git operation, the whole sln will be opened instead of slnf.

It's because VS is treating slnf as sln with a status, not a separated entry. Maybe we should notify VS team to improve this.