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

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

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

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

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