Sdk: dotnet sln: support for custom configurations

Created on 1 Jul 2019  路  7Comments  路  Source: dotnet/sdk

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.

enhancement help wanted

Most helpful comment

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.

All 7 comments

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?

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.

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?

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.

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

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

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.

Was this page helpful?
0 / 5 - 0 ratings