[Feature Request]: Support building the new Visual Studio solution file format (.slnx)

[baronfel]

Summary

The VS team has a new XML-based format for solution files that simplifies the current sln file format. When released, it will have an open-source parser, so tools like MSBuild and the dotnet CLI can consistently operate on the format. The new format is intended to reduce common customer pains like merge conflicts and readability, but not to drastically change the experience of working with solutions. MSBuild should be able to build these solutions.

Background and Motivation

For many developers, not being able to build this format will result in not using the new format at all - what use is an IDE-only file when your CI/CD system cannot process it?

Proposed Feature

We should support accepting .slnx files for builds, using all of the same rules as .sln files today. We should

• accept up to one slnx file if present in a directory as an argument to MSBuild
• the presence of multiple sln, slnx, or projects in a directory should result in an ambiguity error
• we should translate the slnx model to a metaproject that builds in the same manner as sln metaprojects today

This will require an OSS and public parser from the VS team to handle the new format.

Alternative Designs

No response

[itn3000]

Issue about slnx was created in past in msbuild and roslyn project.

• MSBuildWorkspace.OpenSolutionAsync fails with the new slnx files roslyn#73004
• [Feature Request]: SolutionFile.Parse doesn't work with the new slnx file #10012
  Should Roslyn or MSBuild handle it?

[baronfel]

We all have independent units of work to do - but I expect MSBuild will need to be the 'first mover' before Roslyn can update to support the new format.

[baronfel]

Roslyn's MSBuildProjectLoader loads solutions here - it directly uses Microsoft.Build.Construction.SolutionFile.Parse(string path). When MSBuild does this work, we should decide on the merits of transparently handling slnx files in SolutionFile.Parse, or requiring users to use the SLNX file parser manually, or having a new convenience API on top of the 'dance' of determining which solution parser to use.

[rainersigwald]

I feel strongly that we should not extend SolutionFile to handle slnx. The push should be to use the new supported parser, not to extend the buggy MSBuild one and use it in more cases.

[Forgind]

I feel strongly that we should not extend SolutionFile to handle slnx. The push should be to use the new supported parser, not to extend the buggy MSBuild one and use it in more cases.

One potentially interesting question is what to do with SolutionFile once the new parser exists. My favorite option would be to fully delete SolutionFile and just use the other parser, but I strongly suspect that would break way too many people who currently call into our APIs directly. We could instead work to make all our APIs just redirect into the new parser, though we might have to add something extra on top if there aren't perfect analogues. To be pragmatic, it would probably be good to phase in the new parser so the team working on it has a chance to fix any bugs it may have before everyone's build relies on it working flawlessly.

[surayya-MS]

@rainersigwald from our discussion:
Not introducing new API, but changing the behavior. Apply change waves, so that in SolutionFile.Parse

• If the change wave is the newest one (have to look it up which one it is) then use the new parser to parse .slnx and .sln files, throw error if the new parser couldn't parse the file.
• If it is old wave then use the old parser to parse .sln, and for .slnx throw error with new message like "upgrade to parse slnx"

[rainersigwald]

The change wave will be 17.12 :)

[japj]

Quick question, does this new solution format also include support for Directory.Solution.props and Directory.Solution.targets?

According to https://learn.microsoft.com/en-gb/visualstudio/msbuild/customize-solution-build?view=vs-2022 the Directory.Solution.props and Directory.Solution.targets are only supported from MSBuild commandline, not inside VisualStudio