slnx support in the dotnet CLI

[baronfel]

The dotnet CLI should support the new slnx format for building and in the existing solution management commands. It should also help interested users migrate to the new format.

The new format

slnx is an XML-based format 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.

dotnet experiences using solutions

There are three primary ways that the dotnet CLI interacts with solution files today

• building solutions
  • dotnet build myapp.sln
• adding or removing projects and other files from solutions
  • dotnet sln myapp.sln add src/migrations
• creating new solutions
  • dotnet new solution -n lodestone

Each of these should be made to work with the new format to some degree. In addition, a fourth new capability should be added:

• migrating from sln to slnx
  • dotnet sln <sln file> migrate

Building solutions

Status: Done, will be shipping in .NET 9.0.200. Available in VS 17.13 preview 2/.NET SDK 9.0.200-preview

This should be mostly transparent to the dotnet CLI. Much like solutions today, building a solution involves passing the path to the solution file to the MSBuild engine, which has the sole responsibility of converting the build configurations into a 'metaproject' - a kind of MSBuild representation that MSBuild can actually execute - and then building the requested targets on that metaproject.

The same process would hold with slnx - the CLI would forward along the slnx file provided (if any) and MSBuild itself would translate that file into a metaproject and execute that metaproject. Very few changes should be required in the CLI codebase to support this. MSBuild's tracking issue for this is dotnet/msbuild#10266.

Manipulating solution content

Status: In progress - see the linked PRs below.

The CLI has several commands that allow for adding and removing projects in a solution, as well as listing the existing projects. All of these commands should work with slnx as well. This is the area that will require the most investment. The CLI will need to

• learn that slnx files are valid inputs to these commands
• provide some kind of alternative implementation for these commands that works on slnx files
• pivot the implementation used based on the file type provided

These commands allow for selection of the solution file. If invoked in a location where multiple potential solution files are present, the command should error and prompt the user to choose one of the possible solutions.

We'll also need to invest in test coverage to make sure we have parity between our sln support and slnx support.

Creating new solutions

Status: Done, will be shipping in .NET 9.0.200. Available in VS 17.13 preview 2/.NET SDK 9.0.200-preview

The CLI currently ships a solution template that create a new, barebones solution file.

We should provide a template that can create an empty slnx file for users to begin with. The new slnx template should use UTF-8 without a BOM. One major question: should we supplant the existing solution template to create an slnx file? Should the old solution format be accessible via a template parameter?

Migrating existing solutions

Status: Done, will be shipping in .NET 9.0.200. Available in VS 17.13 preview 3

An entirely new capability to migrate a sln file to a new slnx file should be implemented as well to ease onboarding and allow for automation. This command would load the existing sln file and analyze it, translating it into an equivalent slnx file. Ideally any data that matches the default conventions of the new slnx format (for example, default build configurations like Debug and Release) could be omitted from the generated slnx file. The migrated slnx file will be written alongside the existing solution to allow for easy reverting/recovery of the change. The solution file to act upon will follow our existing SlnArgument pattern - if an exact path is used, use that sln. If a directory is provided, and there is only one solution file, use that solution file. If a directory is provided and there are multiple solution files, error.

Note that the addition of this slnx file will likely cause 'bare', unspecified MSBuild commands (like dotnet build without an explicit solution argument) as well as dotnet sln commands with no arguments to fail when used in the working directory - this is acceptable. Users can test by explicitly building the new slnx, and then delete the previous .sln file when they are satisfied with the behaviors.

References

• Twitter Survey
• Mastodon survey

[glen-84]

Regarding the solution template, would it possible to exclude the byte order mark (BOM) now, or are there still known issues with VS or msbuild?

I know that:

1. The Unicode Standard does not recommend its use.
2. Even applications like Notepad now use UTF-8 without BOM by default. (source)

[baronfel]

@glen-84 I'm inclined to make that change, but would like to discuss with @rainersigwald and the rest of the MSBuild team about any gaps there.

[rainersigwald]

For .sln I would leave it as it has been (I believe that's the longstanding Windows 16-bit chars with BOM).

For .slnx we should definitely avoid the BOM but would need to check with the VS folks to make sure they agree.

[baronfel]

I've reached out to the VS side to check compatibility with no-BOM.

[baronfel]

The VS team confirmed that slnx defaults to UTF-8 No-BOM, so we are clear to default the slnx template contents to no-BOM as well. I've updated the description to match this.

[vaind]

Is there any concrete plan for this? I'm looking forward to build/test/restore support for slnx (also when referenced from a .slnf) so that we can update Sentry .NET SDK to use the new format.. Adding projects to the old format is so cumbersome when you need to keep a PR reviewable.

[baronfel]

We are still waiting for an official parser library for the new format to be made available by our partner teams. We're unable to make any progress without that library (and the stabilized format spec implied by that)

[kasperk81]

related microsoft/slngen#585

[kasperk81]

if the plan is still to include slnx support in sdk 9.0, is there any estimate when parsing library is going to be available on github?

[baronfel]

Not at this time, no.

[kasperk81]

it will have an open-source parser

even if it's not fully ready it can still be open sourced today and people can help fixing the remaining bugs in a few hours. someone did similar work starting five months ago https://github.com/winscripter/Slnx so they can collaborate with community

[ssg]

dotnet test also parses sln files to find test projects and fails to work with slnx, fyi.

[aradalvand]

Still waiting for this.
Stuff like this makes it feel like Microsoft still sees non-Visual-Studio users of .NET as second-class citizens; which is disappointing after all these years.

[ite-klass]

Still waiting for this. Stuff like this makes it feel like Microsoft still sees non-Visual-Studio users of .NET as second-class citizens; which is disappointing after all these years.

It's not like slnx works very well in VS. It's an experimental preview feature. And even with VS, CI requires dotnet CLI.

[chucker]

Stuff like this makes it feel like Microsoft still sees non-Visual-Studio users of .NET as second-class citizens

It's not a non-preview feature yet in VS (I believe the release notes still don't mention it at all), and the API isn't considered stable.

[baronfel]

A status update for those following this issue:

• The new parser is now open-source, and the repository can be found at https://github.com/microsoft/vs-solutionpersistence
• MSBuild has a PR that enables support for building slnx files at .SLNX format support msbuild#10794
• We will have to wait for the slnx parser to be onboarded to source-build-externals in this PR before we can merge the MSBuild PR.
• The SDK codeflow for the slnx functionality is [release/9.0.2xx] Update dependencies from dotnet/msbuild #44283

Our current plan is to try to merge this change and get support for building slnx files from the .NET SDK in a preview release of the 9.0.200 SDK, but that is subject to some timelines that we are still navigating.

[kasperk81]

Proposal:
dotnet new sln -n lodestone -f slnx short for dotnet new solution --name lodestone --format slnx

In .NET 9.0, the default format (-f) is still .sln. However, by .NET 10.0 or 11.0, consider making .slnx the default format to encourage developers to upgrade to Visual Studio versions that would fully support it by then. This gradual switch ensures backward compatibility while pushing adoption of the cleaner, modern solution format.

[baronfel]

@kasperk81 From the issue description:

One major question: should we supplant the existing solution template to create an slnx file? Should the old solution format be accessible via a template parameter?

Switching the defaults for .NET 10 is a fine plan, and is what we had been internally considering anyway.

[richshadman]

@richshadman have you considered using MSBuild projects that point to the projects you care about (maybe using Microsoft.Build.Traversal, instead of synthesizing solutions? Then you could have MSBuild conditions, and it'd probably be generally easier to debug.

No I have not - I will look into that.

VS 17.12 was released today. Any update on .NET 8 support for slnx by chance?

[JohnGalt1717]

I can tell you that in 17.12 and 17.13 P1 don't even support SLNX for jumplists properly, and the upgrade tool also doesn't work.

It's a half-baked mess.

[bamancio-futura]

how is this still "untriaged" ?

[kasperk81]

sln-add is now available in the daily (net10) build, and I’ve got some strong opinions about the mandatory random GUID it’s adding to each <Project node: #44570 (comment). What do you all think?

The whole point of .slnx was to avoid GUIDs wherever possible. Without the Id={guid} part in <Project Path="{path}" Id="{guid}" />, Visual Studio opens the solution just fine, and MSBuild has no issues building it. So, why is the SDK randomly generating project GUIDs for .slnx?

Currently, if a project file has a <ProjectGuid> (legacy) property, it uses that value, which is fine. The problem is when <ProjectGuid> isn’t present (which is a common occurrence in modern projects) it randomly generates a GUID, and that’s not the desired behavior.

[julealgon]

sln-add is now available in the daily (net10) build, and I’ve got some strong opinions about the mandatory random GUID it’s adding to each <Project node: #44570 (comment). What do you all think?

Oh boy please don't add guids back in this, that substantially defeats the purpose of the new format.

[edvilme]

sln-add is now available in the daily (net10) build, and I’ve got some strong opinions about the mandatory random GUID it’s adding to each <Project node: #44570 (comment). What do you all think?

The whole point of .slnx was to avoid GUIDs wherever possible. Without the Id={guid} part in <Project Path="{path}" Id="{guid}" />, Visual Studio opens the solution just fine, and MSBuild has no issues building it. So, why is the SDK randomly generating project GUIDs for .slnx?

Currently, if a project file has a <ProjectGuid> (legacy) property, it uses that value, which is fine. The problem is when <ProjectGuid> isn’t present (which is a common occurrence in modern projects) it randomly generates a GUID, and that’s not the desired behavior.

THanks for pointing this out! You are absolutely right, this is addressed in #45366

[philipp-naused]

It looks like .NET SDK 9.0.200-preview.0.24575.35 is now included in Visual Studio 2022 17.13.0-pre.2.0.
Both the dotnet.exe and MSBuild.exe included in this preview support the new format.

[kasperk81]

9.0.200-preview.0.24575.35 is missing sln-add and sln-list command support for slnx. 9.0 backport is in progress #45408. last part (sln remove) is also in progress #45160. matter of few more days

[edvilme]

Update: dotnet sln migrate, dotnet sln list, dotnet sln add, dotnet sln remove already merged to 9.0.2xx :)

[philipp-naused]

Is there an overview of which commands are still missing?
e.g: dotnet format https://github.com/dotnet/sdk/blob/bee76bdbc2becae706389ef70ae51171ba199e7a/src/BuiltInTools/dotnet-format/Workspaces/MSBuildWorkspaceFinder.cs#L79C9-L80C110
and dotnet workload restore https://github.com/dotnet/sdk/blob/main/src/Cli/dotnet/commands/dotnet-workload/restore/WorkloadRestoreCommand.cs

[edvilme]

Is there an overview of which commands are still missing? e.g: dotnet format https://github.com/dotnet/sdk/blob/bee76bdbc2becae706389ef70ae51171ba199e7a/src/BuiltInTools/dotnet-format/Workspaces/MSBuildWorkspaceFinder.cs#L79C9-L80C110 and dotnet workload restore https://github.com/dotnet/sdk/blob/main/src/Cli/dotnet/commands/dotnet-workload/restore/WorkloadRestoreCommand.cs

Yes, the plan is to currently remove all instances of the previous parser and replace with vs-solutionpersistence, as well as adding discovery for .slnx files in other areas that forward to MSBuild #45442

[dominikjeske]

I have tested latest SDK and most things are working but still we can't add files that are not project files. Are there any plans for this?

[edvilme]

Hello @dominikjeske yes, there are plans to introduce that feature, please refer to #9611
Work had been paused while support for the new format was added to the existing commands

[edvilme]

Tagging #46002 for future reference: Refactor sln(x) + add support for slnf

[julealgon]

@edvilme when do you expect we will see official slnx support completed? Will that be announced as part of a specific Visual Studio update?

I just wanted to keep close track of that so we can jump into it as soon as possible on our side.

[baronfel]

Hi @julealgon -

VS today supports building with SLNX files, but the rest of the CLI-based ecosystem does not. In next month's 9.0.200 SDK release (which will ship with VS 17.13), the CLI will be able to support SLNX files as well. Other IDEs like VSCode and Rider may not yet support SLNX still - you'll need to reach out to those products to check their expected timelines.

Even with 9.0.200 supporting SLNX formats, though, the VS IDE itself doesn't have the format enabled as a default. If you'd like to migrate you'll need to enable the option for every developer that will work on your solution.

[julealgon]

VS today supports building with SLNX files, but the rest of the CLI-based ecosystem does not.

Yeah, sorry, I should've clarified I meant comprehensive support. I already did a few tests with slnx locally here with VS so I was aware there was already support in the IDE.

In next month's 9.0.200 SDK release (which will ship with VS 17.13), the CLI will be able to support SLNX files as well.

This is precisely what I was looking for. I appreciate you sharing that @baronfel.

Even with 9.0.200 supporting SLNX formats, though, the VS IDE itself doesn't have the format enabled as a default. If you'd like to migrate you'll need to enable the option for every developer that will work on your solution.

Do you think it will have support enabled by default by version 17.13? The fact that we would have to ask all developers to change this setting manually does make this harder to adopt for us. If default support is coming in an even later release, we might end up waiting for that before we make the switch.

[philipp-naused]

Is there any reason it shouldn't be enabled by default in 17.13?
Why hide it in the "Preview Features" tab if it only adds support for a new format?