Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Tracked by #10324
baronfel opened this issue Jun 19, 2024 · 14 comments · Fixed by #10794
Closed
Tracked by #10324
Assignees
Labels
Epic Groups multiple user stories. Can be grouped under a theme. Feature Request

Comments

@baronfel
Copy link
Member

baronfel commented Jun 19, 2024

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
Copy link

itn3000 commented Jun 20, 2024

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

@baronfel
Copy link
Member Author

baronfel commented Jun 20, 2024

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
Copy link
Member Author

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
Copy link
Member

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.

@tkapin tkapin added the Epic Groups multiple user stories. Can be grouped under a theme. label Jul 11, 2024
@Forgind
Copy link
Member

Forgind commented Jul 12, 2024

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
Copy link
Member

surayya-MS commented Jul 15, 2024

@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
Copy link
Member

The change wave will be 17.12 :)

@japj
Copy link

japj commented Jul 17, 2024

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

@baronfel
Copy link
Member Author

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.

@rainersigwald
Copy link
Member

It should support them the same way we do today: only when building in MSBuild/dotnet build.

@JanKrivanek
Copy link
Member

@winscripter
Copy link

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.

@tkapin
Copy link
Member

tkapin commented Aug 16, 2024

What exactly is this issue blocked on? Is there something that could be done to unblock it?

@rainersigwald
Copy link
Member

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Epic Groups multiple user stories. Can be grouped under a theme. Feature Request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants