[Discussion] Clean up sln (VisualStudio solution) files

From @chrisaut on February 21, 2017 4:32

Now that the csproj files are somewhat clean, are there plans to similarly clean up .sln files?

A sample solution with just two projects looks like this today:

Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 15
VisualStudioVersion = 15.0.26206.0
MinimumVisualStudioVersion = 10.0.40219.1
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "coreDemo", "coreDemo\coreDemo.csproj", "{1A6AEDEC-9638-465A-9EEE-7CC718C12DED}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "netStdLib", "netStdLib\netStdLib.csproj", "{EEE8E2FD-7DAF-4AAC-8A2C-8B5D4A159B56}"
EndProject
Global
	GlobalSection(SolutionConfigurationPlatforms) = preSolution
		Debug|Any CPU = Debug|Any CPU
		Debug|x64 = Debug|x64
		Debug|x86 = Debug|x86
		Release|Any CPU = Release|Any CPU
		Release|x64 = Release|x64
		Release|x86 = Release|x86
	EndGlobalSection
	GlobalSection(ProjectConfigurationPlatforms) = postSolution
		{1A6AEDEC-9638-465A-9EEE-7CC718C12DED}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
		{1A6AEDEC-9638-465A-9EEE-7CC718C12DED}.Debug|Any CPU.Build.0 = Debug|Any CPU
		{1A6AEDEC-9638-465A-9EEE-7CC718C12DED}.Debug|x64.ActiveCfg = Debug|x64
		{1A6AEDEC-9638-465A-9EEE-7CC718C12DED}.Debug|x64.Build.0 = Debug|x64
		{1A6AEDEC-9638-465A-9EEE-7CC718C12DED}.Debug|x86.ActiveCfg = Debug|x86
		{1A6AEDEC-9638-465A-9EEE-7CC718C12DED}.Debug|x86.Build.0 = Debug|x86
		{1A6AEDEC-9638-465A-9EEE-7CC718C12DED}.Release|Any CPU.ActiveCfg = Release|Any CPU
		{1A6AEDEC-9638-465A-9EEE-7CC718C12DED}.Release|Any CPU.Build.0 = Release|Any CPU
		{1A6AEDEC-9638-465A-9EEE-7CC718C12DED}.Release|x64.ActiveCfg = Release|x64
		{1A6AEDEC-9638-465A-9EEE-7CC718C12DED}.Release|x64.Build.0 = Release|x64
		{1A6AEDEC-9638-465A-9EEE-7CC718C12DED}.Release|x86.ActiveCfg = Release|x86
		{1A6AEDEC-9638-465A-9EEE-7CC718C12DED}.Release|x86.Build.0 = Release|x86
		{EEE8E2FD-7DAF-4AAC-8A2C-8B5D4A159B56}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
		{EEE8E2FD-7DAF-4AAC-8A2C-8B5D4A159B56}.Debug|Any CPU.Build.0 = Debug|Any CPU
		{EEE8E2FD-7DAF-4AAC-8A2C-8B5D4A159B56}.Debug|x64.ActiveCfg = Debug|x64
		{EEE8E2FD-7DAF-4AAC-8A2C-8B5D4A159B56}.Debug|x64.Build.0 = Debug|x64
		{EEE8E2FD-7DAF-4AAC-8A2C-8B5D4A159B56}.Debug|x86.ActiveCfg = Debug|x86
		{EEE8E2FD-7DAF-4AAC-8A2C-8B5D4A159B56}.Debug|x86.Build.0 = Debug|x86
		{EEE8E2FD-7DAF-4AAC-8A2C-8B5D4A159B56}.Release|Any CPU.ActiveCfg = Release|Any CPU
		{EEE8E2FD-7DAF-4AAC-8A2C-8B5D4A159B56}.Release|Any CPU.Build.0 = Release|Any CPU
		{EEE8E2FD-7DAF-4AAC-8A2C-8B5D4A159B56}.Release|x64.ActiveCfg = Release|x64
		{EEE8E2FD-7DAF-4AAC-8A2C-8B5D4A159B56}.Release|x64.Build.0 = Release|x64
		{EEE8E2FD-7DAF-4AAC-8A2C-8B5D4A159B56}.Release|x86.ActiveCfg = Release|x86
		{EEE8E2FD-7DAF-4AAC-8A2C-8B5D4A159B56}.Release|x86.Build.0 = Release|x86
	EndGlobalSection
	GlobalSection(SolutionProperties) = preSolution
		HideSolutionNode = FALSE
	EndGlobalSection
EndGlobal

I see 3 “sections”: 1) Information about VS, which version created it and the minimum version 2) List or projects and their locations 3) Solution and ProjectConfigurationPlatforms

1. Is the VisualStudio stuff really needed? I regularly run into changes here when opening solutions in different versions, it creates a change for no apparent reason.

2. Can we get rid of the GUIDs for the project lists? Also the logical name (coreDemo, netStdLib) in addition to the csproj, can this just be infered for the probably 99.99% case when the two match?

3. I can’t say much about the ConfigurationPlatform stuff, except that it looks messy. I feel like this should be pulled out somehow.

Since everything is going xml (…I know, I know), perhaps the format of the sln file should also be xml. A minimalistic solution could look something like this:

<Solution MinimumVisualStudioVersion="10.0.40219.1">
  <Projects>
    <Project Location="coreDemo\coreDemo.csproj" Type="netCoreConsole" ProjectConfigurationPlatforms="Default" />
    <Project Location="netStdLib\netStdLib.csproj" Type="netStandardLib" >
        <ProjectConfigurationPlatforms>
            <ConfigurationPlatform Configuration="Release" Platform="x64" />
            <ConfigurationPlatform Configuration="Release" Platform="x86" />
        </ProjectConfigurationPlatforms>
    </Project>
  </Projects>
  <SolutionConfigurationPlatforms>
    <ConfigurationPlatform Configuration="Release" Platform="x64" />
    <ConfigurationPlatform Configuration="Release" Platform="x86" />
  </SolutionConfigurationPlatforms>
</Solution>

A few things to note: The Project Type Guids (“FAE04EC0-301F-11D3-BF4B-00C04F79EFBC”, at least that’s what I think those are) are messy, if this is really needed by VS for some reason let’s please make it a string that makes sense for humans (“netCoreConsole” in the example). We pull the ProjectConfigurations into the projects where they logically belong. Also, while at times custom platform/configurations are needed, most of the time people I think just use the default (x86/x64/Any CPU)/(Debug/Release). So we just make those the default. For the project list we could also do the filepattern thing (**/*.csproj) but I feel like projects aren’t added/removed often enough to warrant this, so perhaps being explicit here is the better choice.

I just want to start this issue so that a discussion can be started, I’m by no means an expert on this stuff.

Copied from original issue: dotnet/roslyn-project-system#1594

[dasMulli]

+1 for a native MSBuild format. It would be awesome to have it as “simple” as

<Project Sdk="Microsoft.Sln.Sdk">
  <ItemGroup>
    <SolutionProject Include="**\*.*proj" />
  </ItemGroup>
</Project>

[stijnherreman]

This has been put off for almost 15 years now, so I’m pessimistic–but it’s a totally reasonable request, and maybe now is the time it can actually get done.

@rainersigwald 3 years later the situation seems to be unchanged, has the chance of this happening increased or decreased?

It’s the second most 👍 issue here, only surpassed by #613. The UserVoice someone linked no longer exists. What can we do as customers to give this request a higher priority?