dotnet
[Feature Request]: Support building the new Visual Studio solution file format (.slnx)
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
Issue about slnx was created in past in msbuild and roslyn project.
- https://github.com/dotnet/roslyn/issues/73004
- https://github.com/dotnet/msbuild/issues/10012 Should Roslyn or MSBuild handle it?
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.
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.
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.
I feel strongly that we should not extend
SolutionFileto 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.
@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"
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
I can check with the Solution dev team, but I would not expect support for those files to be added - the semantics of the solution file aren't changing with the new format, just the format of the file.
It should support them the same way we do today: only when building in MSBuild/dotnet build.
Surayya`s PR (internal): https://devdiv.visualstudio.com/DevDiv/_git/DotNet-msbuild-Trusted/pullrequest/569790
I have wrote an SLNX file parser a few months ago. While I'm not certain if it directly assists with building SLNX files, it might be worth considering.
What exactly is this issue blocked on? Is there something that could be done to unblock it?
@tkapin it is blocked on the availability of the library we need from the VS solution folks in a form we can consume it. Right now we have some prototype work based on their Microsoft-internal code.
@tkapin it is blocked on the availability of the library we need from the VS solution folks in a form we can consume it. Right now we have some prototype work based on their Microsoft-internal code.
Are you talking about this? https://github.com/microsoft/vs-solutionpersistence
