Enable dotnet sln to add SLN-level files

[richlander]

I wasn't able to add SLN-level files to a .sln file with the commandline tools. VS enables me to do this.

[John0King]

I hope that I can do the follow thing with dotnet sln :

1. add a solution folder
2. add a project to a folder

Project.sln
|---src
      |-- A.csproj
      |-- B.csproj

[LordMike]

I'd like to do what @John0King suggests: Be able to specify a "target solution directory" for anything I might add.

Example commandlines I'd want:

dotnet sln MySolution.sln add --target "src" src\MyProject\MyProject.csproj src\MyOtherProject\MyOtherProject.csproj
dotnet sln MySolution.sln add --target "GlobalFiles" imports\common.targets

Essentially controlling, both for projects and files, the target inside the solution file. If possible, the add command should also move existing projects within the solution (possibly by a --allow-move argument), so that this also works:

dotnet sln MySolution.sln add --target "srrrrrrrc" src\MyProject\MyProject.csproj

# correct spelling mistake in srrrr...
dotnet sln MySolution.sln add --target "src" src\MyProject\MyProject.csproj

[LordMike]

@richlander do you think this can be done as a community contribution?

Edit: It seems pretty straight forward. The SlnFile supports adding/changing stuff, and there's a bunch of extensions on it to add projects, solution folders and more.

[livarcocc]

cc @peterhuene who has been driving our community contributions.

[peterhuene]

We currently have a related community PR to add an option to add the project to the "root" without any solution folders: dotnet/cli#10873

This is similar in intent to the issue, although I think adding another option for a "solution folder target" (a path) to create in the solution to add the project to would also be a great addition.

I think this would be a great candidate for a community contribution.

[LordMike]

@peterhuene I've submitted a PR, dotnet/cli#11000

[LordMike]

@peterhuene now that dotnet/cli#11000 is in, can we look at adding arbitrary files in solution files? :)

[peterhuene]

@LordMike that's not a bad idea. Let me check with @KathleenDollard to see if the feature makes sense for our scenarios.

[LordMike]

I would argue that since you in VS can add any file as a solution-level file, you should be able to do this from the CLI as well.

Concretely, we have a use case where we have a bunch of solution files in a single repository, each for a small partition of the overall product. To maintain these (we regularly add or remove projects), I've created a .NET program that reconstructs a project graph (follows imports and references) to add projects to solutions (by building a dotnet sln commandline). One thing it's lacking though, is the ability to add common files, such as readmes or CI setups into all repositories.

Although. This setup may be superseded by filtered solutions in VS2019.

[KathleenDollard]

I really like aspects of this!

Looks good, except the --target switch name, which I understand which has been changed to --solution-folder. Which sounds great.

If we ever did the --allow-move, let's make it a different PR.

[LordMike]

@KathleenDollard what do you think about the ability to dotnet sln add readme.md ?

[KathleenDollard]

I think this makes more sense as a template. What would you put in it?

[LordMike]

Ah, no, Readme.md was just a name of a file that isn't a .csproj.. It could be anything.. such as dotnet sln add <file-that-is-not-csproj>. The example command will fail today, since the add only works on project files, even though the sln format allows any file.

My question is how you'd feel about the ability to add these extra files using the CLI.. ? :)

[dasMulli]

I'd be a happy uer of the feature, being able to add all my build.props / targets and Directory.Build.props of various folder levels to a solution (including automatic solution folders) without dying of age using the VS UI.

[LordMike]

@peterhuene any new thoughts on this, or news from Camp Microsoft? :)

[rlove]

Today I wanted to add YAML files to the Solution as part of Microservice Solution generation script. This feature would make that possible.

[tmay57]

In addition, you should be able to added such a file to a solution folder. It is very common to see a solution folder called something like "SolutionItems" with "config and readme" type files grouped into it. If you can do it in Visual Studio you should be able to do it in dotnet cli or you build in a feature gap that makes it hard for folks to move existing workflow from Visual Studio into a dotnet cli workflow.

[LordMike]

One of my contributions to dotnet sln was the ability to control the solution folder on add.. So it should be covered.

>dotnet sln add --help
Usage: dotnet sln <SLN_FILE> add [options] <PROJECT_PATH>

Arguments:
  <SLN_FILE>       The solution file to operate on. If not specified, the command will search the current directory for one.
  <PROJECT_PATH>   The paths to the projects to add to the solution.

Options:
  --in-root               Place project in root of the solution, rather than creating a solution folder.
  -s, --solution-folder   The destination solution folder path to add the projects to. <----- Here.
  -h, --help              Show command line help.

[tmay57]

Thank you for the contribution and this works for projects just fine. However, it doesn't allow for a file to be added. It would be sweet if it did.
FWIW, we are building a project/code generation tool and because of the limitations of the CLI we decided to just bring a copy of the Cli.Sln.Internal project into our app so we can do everything we need without using the Process class.

[samsmithnz]

Another vote for this. Having the ability to add existing files to the solution would be very useful. Even something a call for each separate file would work for me:

dotnet sln add --file 'README.MD'
dotnet sln add --file '.github/workflows/workflow.yml'

[baronfel]

I'm going to close this one as a duplicate of #9611 because I've sketched out a spec for the functionality we'd want over there. The issue is marked up-for-grabs, but we may take another look at this later in the summer as we look at integrating the slnx file format support into the CLI's solution-management commands.