{"id":55826,"date":"2025-03-13T10:30:00","date_gmt":"2025-03-13T17:30:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/dotnet\/?p=55826"},"modified":"2025-07-24T13:38:46","modified_gmt":"2025-07-24T20:38:46","slug":"introducing-slnx-support-dotnet-cli","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/introducing-slnx-support-dotnet-cli\/","title":{"rendered":"Introducing support for SLNX, a new, simpler solution file format in the .NET CLI"},"content":{"rendered":"

Solution files have been a part of the .NET and Visual Studio experience for many years now, and they’ve had the same custom format the whole time. Recently, the Visual Studio solution team has begun previewing a new<\/a>, XML-based solution file format called SLNX. Starting in .NET SDK 9.0.200, the dotnet<\/code> CLI supports building and interacting with these files in the same way as it does with existing solution files. In the rest of this post we’ll show how users can migrate to the new format, explore the new support across the dotnet<\/code> CLI, and discuss the next steps towards a generally-available release of the format.<\/p>\n

Getting started<\/h2>\n

Before the 9.0.200 SDK, the only way to create a SLNX file was through the Visual Studio settings. The Environment > Preview Features > Use Solution File Persistence Model<\/code> setting, when checked, would allow users to Save As<\/code> their existing .sln<\/code> files in the new .slnx<\/code> format. Starting in Visual Studio 17.14, this feature is stable and generally available.<\/p>\n

The 9.0.200 SDK provides a command to do this same migration: dotnet sln migrate<\/code>.<\/p>\n

Let’s start with a very simple solution and project setup to look at what it takes to migrate. First, we’ll create a new solution:<\/p>\n

PS C:\\Users\\chethusk\\Code\\example> dotnet new sln\nThe template \"Solution File\" was created successfully.\n\nPS C:\\Users\\chethusk\\Code\\example> cat .\\example.sln\n\nMicrosoft Visual Studio Solution File, Format Version 12.00\n# Visual Studio Version 17\nVisualStudioVersion = 17.0.31903.59\nMinimumVisualStudioVersion = 10.0.40219.1\nGlobal\n        GlobalSection(SolutionConfigurationPlatforms) = preSolution\n                Debug|Any CPU = Debug|Any CPU\n                Release|Any CPU = Release|Any CPU\n        EndGlobalSection\n        GlobalSection(SolutionProperties) = preSolution\n                HideSolutionNode = FALSE\n        EndGlobalSection\nEndGlobal<\/code><\/pre>\n
Now, we’ll create a project and add it to the solution:<\/p>\n
\nPS C:\\Users\\chethusk\\Code\\example> dotnet new console -n my-app\nThe template \"Console App\" was created successfully.\n\nProcessing post-creation actions...\nRestoring C:\\Users\\chethusk\\Code\\example\\my-app\\my-app.csproj:\nRestore succeeded.\n\nPS C:\\Users\\chethusk\\Code\\example> dotnet sln add .\\my-app\\\nProject `my-app\\my-app.csproj` added to the solution.\n\nPS C:\\Users\\chethusk\\Code\\example> cat .\\example.sln\n\nMicrosoft Visual Studio Solution File, Format Version 12.00\n# Visual Studio Version 17\nVisualStudioVersion = 17.0.31903.59\nMinimumVisualStudioVersion = 10.0.40219.1\nProject(\"{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}\") = \"my-app\", \"my-app\\my-app.csproj\", \"{845B7716-6F03-4D02-8E86-79F95485B5D7}\"\nEndProject\nGlobal\n        GlobalSection(SolutionConfigurationPlatforms) = preSolution\n                Debug|Any CPU = Debug|Any CPU\n                Debug|x64 = Debug|x64\n                Debug|x86 = Debug|x86\n                Release|Any CPU = Release|Any CPU\n                Release|x64 = Release|x64\n                Release|x86 = Release|x86\n        EndGlobalSection\n        GlobalSection(ProjectConfigurationPlatforms) = postSolution\n                {845B7716-6F03-4D02-8E86-79F95485B5D7}.Debug|Any CPU.ActiveCfg = Debug|Any CPU\n                {845B7716-6F03-4D02-8E86-79F95485B5D7}.Debug|Any CPU.Build.0 = Debug|Any CPU\n                {845B7716-6F03-4D02-8E86-79F95485B5D7}.Debug|x64.ActiveCfg = Debug|Any CPU\n                {845B7716-6F03-4D02-8E86-79F95485B5D7}.Debug|x64.Build.0 = Debug|Any CPU\n                {845B7716-6F03-4D02-8E86-79F95485B5D7}.Debug|x86.ActiveCfg = Debug|Any CPU\n                {845B7716-6F03-4D02-8E86-79F95485B5D7}.Debug|x86.Build.0 = Debug|Any CPU\n                {845B7716-6F03-4D02-8E86-79F95485B5D7}.Release|Any CPU.ActiveCfg = Release|Any CPU\n                {845B7716-6F03-4D02-8E86-79F95485B5D7}.Release|Any CPU.Build.0 = Release|Any CPU\n                {845B7716-6F03-4D02-8E86-79F95485B5D7}.Release|x64.ActiveCfg = Release|Any CPU\n                {845B7716-6F03-4D02-8E86-79F95485B5D7}.Release|x64.Build.0 = Release|Any CPU\n                {845B7716-6F03-4D02-8E86-79F95485B5D7}.Release|x86.ActiveCfg = Release|Any CPU\n                {845B7716-6F03-4D02-8E86-79F95485B5D7}.Release|x86.Build.0 = Release|Any CPU\n        EndGlobalSection\n        GlobalSection(SolutionProperties) = preSolution\n                HideSolutionNode = FALSE\n        EndGlobalSection\nEndGlobal<\/code><\/pre>\n
Now, let’s convert our solution to the new format:<\/p>\n
PS C:\\Users\\chethusk\\Code\\example> dotnet sln migrate\n.slnx file C:\\Users\\chethusk\\Code\\example\\example.slnx generated.\nPS C:\\Users\\chethusk\\Code\\example> cat .\\example.slnx\n<Solution>\n  <Configurations>\n    <Platform Name=\"Any CPU\" \/>\n    <Platform Name=\"x64\" \/>\n    <Platform Name=\"x86\" \/>\n  <\/Configurations>\n  <Project Path=\"my-app\/my-app.csproj\" \/>\n<\/Solution><\/code><\/pre>\n
The new format is XML-based and is much more concise than the old format – but it contains all of the same data! The data that is missing from the new format is part of the defaults of the format, so no functionality is lost.<\/p>\n
This migration is made possible because the Visual Studio Solution team has created a new open-source library for parsing and working with both classic and XML-based solution files – the library is called Microsoft.VisualStudio.SolutionPersistence<\/a>.<\/p>\n
Managing projects from the CLI<\/h2>\n
You can do more than migrating solution files using the CLI, too. As you might expect, you can build the new solutions the same way you would build the old:<\/p>\n
PS C:\\Users\\chethusk\\Code\\example> dotnet build .\\example.slnx\nRestore complete (0.6s)\n  my-app succeeded (4.3s) \u2192 my-app\\bin\\Debug\\net9.0\\my-app.dll\n\nBuild succeeded in 5.3s<\/code><\/pre>\n
<\/i>Note<\/strong><\/p> We specified the .slnx<\/code> file explicitly above because it’s an error to run dotnet build<\/code> or other commands that need to build in a directory with both a .sln<\/code> and a .slnx<\/code> – we don’t know which one to build!<\/div><\/p>\n
All of the other interactions you expect from the dotnet<\/code> CLI work as well. We can add projects:<\/p>\n
PS C:\\Users\\chethusk\\Code\\example> dotnet new classlib -n my-lib\nThe template \"Class Library\" was created successfully.\n\nProcessing post-creation actions...\nRestoring C:\\Users\\chethusk\\Code\\example\\my-lib\\my-lib.csproj:\nRestore succeeded.\n\nPS C:\\Users\\chethusk\\Code\\example> dotnet sln .\\example.slnx add my-lib\nProject `my-lib\\my-lib.csproj` added to the solution.\n\nPS C:\\Users\\chethusk\\Code\\example> cat .\\example.slnx\n<Solution>\n  <Configurations>\n    <Platform Name=\"Any CPU\" \/>\n    <Platform Name=\"x64\" \/>\n    <Platform Name=\"x86\" \/>\n  <\/Configurations>\n  <Project Path=\"my-app\/my-app.csproj\" \/>\n  <Project Path=\"my-lib\/my-lib.csproj\" \/>\n<\/Solution><\/code><\/pre>\n
We can list the projects in a solution:<\/p>\n
PS C:\\Users\\chethusk\\Code\\example> dotnet sln .\\example.slnx list\nProject(s)\n----------\nmy-app\\my-app.csproj\nmy-lib\\my-lib.csproj<\/code><\/pre>\n
And finally we can remove projects from the solution:<\/p>\n
PS C:\\Users\\chethusk\\Code\\example> dotnet sln .\\example.slnx remove .\\my-lib\\\nProject `my-lib\\my-lib.csproj` removed from the solution.\n\nPS C:\\Users\\chethusk\\Code\\example> cat .\\example.slnx\n<Solution>\n  <Configurations>\n    <Platform Name=\"Any CPU\" \/>\n    <Platform Name=\"x64\" \/>\n    <Platform Name=\"x86\" \/>\n  <\/Configurations>\n  <Project Path=\"my-app\/my-app.csproj\" \/>\n<\/Solution><\/code><\/pre>\n
<\/i>Tip<\/strong><\/p>There are two commands that don’t<\/em> work in 9.0.200, though – dotnet nuget why<\/code> and dotnet list package<\/code> – those will begin working in the 9.0.201 release in March.<\/div><\/p>\n
Support for SLNX across .NET IDEs and Tooling<\/h2>\n
As mentioned above, the dotnet<\/code> CLI has broad support for the new SLNX file format, but there are still many tools in the ecosystem that have partial or no support for the format. You will need to take this varying level of support into account when choosing whether to migrate to SLNX files. Some examples of tools that have varying levels of support for slnx today are:<\/p>\n
Visual Studio<\/h3>\n
While the IDE will read the SLNX file when loaded, it currently will not load SLNX files unless the setting to enable SLNX persistence has been enabled. This means if you work on a team and users have not toggled this setting, they will not be able to open SLNX files at all. In addition, double-clicking on SLNX files doesn’t currently open Visual Studio instances the way that sln files do.<\/p>\n