.NET 10 Solution Template not applying Solution Folders on SLNX Solutions

First of all, the new format .slnx is highly recommended. It is simpler than .sln, is based on XML on par with the project files, and is more flexible. Some issues found in the old format are fixed.

(Unfortunately, some advanced features of .slnx format are poorly documented. I discovered some of them with the help of AI and tested. The are gathered from different sources. I won't mention them in this answer. The basic .slnx features fully cover the featues of old .sln format and are quite sufficient for nearly all solutions.)

Solution Folders vs File System Subdirectories

First, you should not confuse the solution folders with file system subdirectories. Basically, the solution folder can be seen as nodes in the Solution Explorer tree, for example, in the IDE like Visual Studio or Visual Studio code. You can see two related structures: file structure and solution structure.

In the Visual Studio Code, you can see two trees in parallel Solution under the EXPLORER pane; they are separated vertically. The top one is the default explorer representing the worskpace file system, it is named after then code directory name. The lower one is called SOLUTION EXPLORER, it reflects the structure of the solution, its nodes provide context menus implementing some more important operations of the dotnet command.

You follow the nice style of structuring solution folders: their name match the names and the file system structure of the subdirectories of the file system. But this is not a requirement. The solution folders are just purely logical nodes unrelated to the file system structure.

Why Solution Folders are not Created?

They are not supposed to be created as file system objects. They represent the structure of the SOLUTION EXPLORER tree. The nodes in this tree are created, but not the physical subdirectories. The rationale behind the structure of the Solution Folders, which can be nested, is: convenience and manageability. This is just a way to structure the solution logically and visually when you work with it via the IDE.

Who Creates the Subdirectories?

You do. When you create a solution folder by editing your .slnx file or via the IDE UI, a SOLUTION EXPLORER Solution Folder node is created. It does not change anything in the file system. To add some content to a Solution Folder, you have to create one or more project files.

Who Creates Project Files?

You do. When you create a project file, you create it in a physical subdirectory of your choice. Naturally, you have to create this subdirectory. There are different ways to do it, in particular:

• You can add a project using the Solution Explorer of Visual Studio or Visual Studio Code. You can do it using a context menu of the Solution explorer node representing the solution, or a Solution Folder (recommended). When you create it and choose the file name, you decide on the location of the project file in the file system. Again, it may or may not match the name of the Solution Folder and the structure of nesting Solution Folders. If you use this way, you create the project node, and the corresponding physical file (optionally, with it directory) as well.

• You can create the .slnx file manually, as you do in your .slnx sample. When this file is created, you have to create the project files with their directories manually. This way has many benefits I will explain below.

• You can create projects of the solution using the .NET CLI command dotnet new. You have to specify the project template. For the list of currently installed templates, use the command dotnet new list.

Creation of the .SLNX File

You can create a new .sln file using the .NET CLI command dotnet new sln --output . It will create a sundirectory of a working directory and a .slnx file with the same name defined by solution-name.

You can also create and edit a solution file manually.

Some Benefits of Manual Creation

By manual creation I mean creation of the solution and project files using the file copy operations and text editor, presumably the one provided by your IDE.

The thing is: in contrast to .NET Framerowk, with .NET, both .slnx and project files are very simple and short, can contain 3-5 lines of code. In a well-developed solutions, you can have several project files with absolutely identical content. This is possible because, by default, the output assembly names are defined by the project file names. You don't need any different contents for, say, different library assemblies or different applications of the same type.

These project files can be further simplified when you generalize then using the file Directory.Build.props, or the hierarchy of these files on different directory levels. These files make the solution structure very efficient and well-maintained by defining common properties for all project or groups of similar projects. For example, all WPF applications can be grouped together and prescribe no information on the assembly type. This information can be prescribed at once in its root Directory.Build.props file. For example:

        $(TargetFramework)-windows
        true
        WinExe

In this example, the properties defined for all projects are imported from the root "$(MSBuildThisFileDirectory)../Directory.Build.props" file, where the common TargetFramework is defined without the frameworks OS-specific part like windows.

It also can contain other shared properties, such as shared version information and other metadata.