`dotnet new sln` cannot create Visual Studio 2022 format *.sln files

Using dotnet new sln, the stub solution file created has the wrong version,

To Reproduce

Run dotnet new sln --name Hello, the contents of Hello.sln will look as follows:

Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio Version 16
VisualStudioVersion = 16.0.30114.105
MinimumVisualStudioVersion = 10.0.40219.1
Global
        GlobalSection(SolutionConfigurationPlatforms) = preSolution
                Debug|Any CPU = Debug|Any CPU
                Release|Any CPU = Release|Any CPU
        EndGlobalSection
        GlobalSection(SolutionProperties) = preSolution
                HideSolutionNode = FALSE
        EndGlobalSection
EndGlobal

This is the version and format for VS 2019. If you now run start Hello.sln it will open in VS 2019, not VS 2022 (if you have both installed). Same when you doubleclick the file in Explorer.

The correct output should have the following:

Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio Version 17
VisualStudioVersion = 17.1.32319.34
MinimumVisualStudioVersion = 10.0.40219.1
Global
        GlobalSection(SolutionProperties) = preSolution
                HideSolutionNode = FALSE
        EndGlobalSection
        GlobalSection(ExtensibilityGlobals) = postSolution
                SolutionGuid = {1258D1A9-B356-4586-948E-D7129920DE48}
        EndGlobalSection
EndGlobal

Note that there are more differences with an empty solution from VS 2022:

• There is no section GlobalSection(SolutionConfigurationPlatforms), ~though I doubt this matters much~ EDIT: this changes the behavior for when you add an existing project. If absent, dotnet sln add will add 6 configurations (debug/release for x86/x64/any), if present, it will only use the already created two configurations. Which approach is better, I don’t know.
• There is a section GlobalSection(ExtensibilityGlobals) which misses with dotnet new sln, which contains the SolutionGuid. Not sure if this is ever used in extensibility, but if it is, it probably should be there, with a unique GUID.

Further technical details

Output from dotnet --info, top part:

.NET SDK (reflecting any global.json):
 Version:   6.0.203
 Commit:    a20feadf6d

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19044
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\6.0.203\

Host (useful for support):
  Version: 6.0.6
  Commit:  7cca709db2

• Using VS 2022

[baronfel]

That’s one of the avenues I’m discussing for sure - changing the VS version in this file, while apparently innocuous, has in the past caused a number of unanticipated issues. I’ve been asked to consult with the VS and Project System teams to see if we hit any of those problems here.

Assuming the actual content change is green-lit, then the question of which versions we should make the change in happens. I’d like to push for both 6.0 releases and 7.0, that way any solution generated from a version of .NET that shipped alongside VS2022 will generate 2022-compatible solution files by default. But it’s all up in the air right now too. I’ll assign this one to myself and put it in a state noting that.

[abelbraaksma]

Thanks, I keep my fingers crossed. .NET 6 will be around much longer than 7, after all.