dotnet sln: support for custom configurations

[stroborobo]

At the moment (3.0.100-preview6) the dotnet sln command only supports adding, removing and listing projects. However it is not possible to change the build configurations, so that has to be done either manually or using e.g. Visual Studio.

It would be nice if you could add and remove configurations from the solution file.

[livarcocc]

We don't currently have plans to add this functionality but this one feels like something we would take a PR for.

@peterhuene what do you think? Does this one feel like a good first issue/community contribution?

[peterhuene]

I think that's a pretty good feature for the community, although the UX might be pretty complex for full fidelity with VS. I think we'd have to design the UX before a first time contributor would be able to run with it.

At a bare minimum, two commands would be needed. One to create a new solution config that maps to any existing project configuration of the same name and platform. If one doesn't exist for a project, we'd have to use the same fallback logic VS uses (I forgot off the top of my head if it's just "first project config / first project platform" or there's some other logic involved). Another command would be needed to remove the solution configuration and related mappings.

We might also need two more commands that correlate to adding/removing project configurations and platforms (confusingly, this would operate on the solution file and not the project file, but we would need the path to the project file as input to resolve the project to modify in the solution file).

An additional command could be implemented that takes a solution configuration name, a path to a project, and a new project config / platform to map the solution configuration to. That should give enough of the editing experience one gets in VS.

I'm going to mark this "help wanted", but leave off the "good first issue" label for now.

[sherry-ummen]

Hi,
(Warning: I don't know everything about sln schema. So I might just be talking rubbish. Please excuse)
The requirement I had was dotnet/cli#12263 for this I was thinking the command like this
dotnet new sln Some.sln /platform x64

And that should generate only those required entries.

Should that be enough to fix my case?

Coming to add or remove config. What are the scenarios we are talking about here? Is it just the platform specific config or there is more to it? Sorry for being ignorant.

Also is there mentoring for these help wanted or good first issues?

[Jalalx]

Hello @peterhuene !
I would like to contribute to this feature. As you mentioned two commands are required:

One to create a new solution config that maps to any existing project configuration of the same name and platform. If one doesn't exist for a project, we'd have to use the same fallback logic VS uses.

Do you mean a command like dotnet sln configure Solution1.sln from ConsoleApp1.csproj which would change a blank solution to:

diff --git a/Solution1.sln b/Solution1.sln
index 28f11e3..4df2ea6 100644
--- a/Solution1.sln
+++ b/Solution1.sln
@@ -3,7 +3,19 @@ Microsoft Visual Studio Solution File, Format Version 12.00
 # Visual Studio 15
 VisualStudioVersion = 15.0.28307.136
 MinimumVisualStudioVersion = 10.0.40219.1
+Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "ConsoleApp1", "ConsoleApp1\ConsoleApp1.csproj", "{0EB355E0-B56C-42EF-B5C7-B25F6B8B2E43}"
+EndProject
 Global
+	GlobalSection(SolutionConfigurationPlatforms) = preSolution
+		Debug|Any CPU = Debug|Any CPU
+		Release|Any CPU = Release|Any CPU
+	EndGlobalSection
+	GlobalSection(ProjectConfigurationPlatforms) = postSolution
+		{0EB355E0-B56C-42EF-B5C7-B25F6B8B2E43}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
+		{0EB355E0-B56C-42EF-B5C7-B25F6B8B2E43}.Debug|Any CPU.Build.0 = Debug|Any CPU
+		{0EB355E0-B56C-42EF-B5C7-B25F6B8B2E43}.Release|Any CPU.ActiveCfg = Release|Any CPU
+		{0EB355E0-B56C-42EF-B5C7-B25F6B8B2E43}.Release|Any CPU.Build.0 = Release|Any CPU
+	EndGlobalSection
 	GlobalSection(SolutionProperties) = preSolution
 		HideSolutionNode = FALSE
 	EndGlobalSection
	GlobalSection(ExtensibilityGlobals) = postSolution
		SolutionGuid = {40E45959-CECC-4586-802A-AC10D40D2A4A}
	EndGlobalSection
EndGlobal

for a default .csproj like this:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.2</TargetFramework>
  </PropertyGroup>
</Project>

Also

Another command would be needed to remove the solution configuration and related mappings.

Something like dotnet sln configure Solution1.sln remove ConsoleApp1.csproj which would remove all configurations related to ConsoleApp1.cspro.

Please correct me if I'm wrong.

[livarcocc]

@KathleenDollard can we work together to figure out what these commands should look like?

[KathleenDollard]

I'm happy to work on the CLI, but I'm afraid I'm way out of touch/recollection on sln files and configuration.

[aolszowka]

You might also want to watch out for the default Visual Studio behavior which IIRC is that for each new Project Configuration, all existing projects receive configuration sections for it as well (even if they were not applicable). In our world it got out of hand very quickly resulting in solution files that were several MB in size due to the possible solution combinations. We settled on enforcing only two "Configurations" which were Debug and Release with AnyCPU Being the platform for both.

[StingyJack]

The requirement I had was dotnet/cli#12263 for this I was thinking the command like this
dotnet new sln Some.sln /platform x64

@sherry-ummen - I could not find that issue (repo moved) so I opened up #16564 to at least get consistency w/ VS. Feel free link to that if you can find your original issue

[tmay57]

One relevant use case for managing configurations with dotnet is using a configuration to specify which projects in a solution should be included in the build process. Solutions may contain projects for server-side and client-side. When doing CI/CD, we use
dotnet build --configuration ServerStack
to build only those projects in the solution that need to be built and deployed to the cloud. This works fine if one is using the Visual Studio IDE Configuration manager to create the ServerStack configuration.

However, if one is working outside of the Visual Studio IDE, then you are forced to manually edit the .sln file. While possible, this is a daunting task for anyone not familiar with the .sln file format.

This issue is a blocker to folks using dotnet in CI/CD pipelines for solutions authored outside of the VS IDE and results in the dotnet CLI being perceived as a second class citizen; thus inhibiting the wide adoption that .NET advocates, like me, are hoping for.

[vrushalivartak]

I have tried to list down below, the CLI commands that would be required in order to achieve the same features as available in Visual Studio's Configuration Manager functionality.
@peterhuene does this make sense? If yes, I can continue working on this ticket? Who can assign the ticket to me?

CLI commands to add/remove/rename the configurations/platforms of all projects within the solution,
dotnet configure sln [<SOLUTION_FILE>] add -c|--config|-p|--platform <name> [-cf|--copyfrom <name>] [-u|--updateproj <y/n>]
dotnet configure sln [<SOLUTION_FILE>] remove -c|--config|-p|--platform <name>
dotnet configure sln [<SOLUTION_FILE>] rename -c|--config|-p|--platform <oldname> <newname>

CLI command to update configuration/platform/build/deploy settings of specific project/s,
dotnet configure sln [<SOLUTION_FILE>]
update [-sc|--solution-config|-sp|solution-platform <name>] [--proj ]
set ([-c|--config <name>] [-p|--platform <name>] [-b|--build <y/n>] [-d|--deploy <y/n>])