Sdk: Add dotnet add|list|remove project commands for solution files

[blackdwarf]

The CLI needs to provide a way for users to manipulate the solution file (SLN file).

Below is a mini-spec of the command.

Usage

`dotnet add project

Top level Verbs

• add
• list
• remove

Arguments

• <project_or_solution>
  
  
  
  • A project or a solution path
  
  
• <project>
  
  
  
  • Path to the project file to include in the SLN file. Has to be a relative path.
  
  

Defaults

• If the <project> is not present, we will try to see if there is a project in the current directory; if there is, it will be added, if not, an error is displayed
• If the <project_or_solution> is not present, we will check the current directory for either a project file or a sln file.
  
  
  
  • If neither are found, an error is displayed
  
  
  • If more than one is found or if there is both sln and a project file present, an error is displayed prompting the user to specify which file the operation should work on.
  
  

Notes

• This command adds a project to a solution if it works on an SLN file. In case a project file, it will add a <ProjectReference> to the project in question.
• The command will make absolute paths of the project being added relative to the solution file/project being added. This is done to avoid messy breaks when moving machines.

Examples

• dotnet add project "../path/to/project.csproj"
  
  
  
  • Add a project found at the specified path to the solution file
  
  
• dotnet remove project "../path/to/project.csproj"
  
  
  
  • Remove a project found at the specified path to the solution file
  
  
• dotnet list path/to/solution.sln project
  
  
  
  • List out all of the projects and configurations from the solution;
  
  

[alexkreskiyan]

@blackdwarf If the following makes sense and is not too late yet =)

Would be nice to operate not only sln file and not only VS-specific stuff.
At least, would be cool to have one commang group, providing through specific commands possibility to generate minimalistic environment for solution.

We have global.json and several project.json files. So, it's possible to locate where to place .sln and .xproj files.

Examples

• dotnet editor vs - in folder with global.json. Creates .sln/.xproj/ or refreshes them carefully (for case of manually changed .sln/.xproj
• dotnet editor vs -f "path/to/global.json" - in other folder
• dotnet editor vs add <project_name> - as far as it's possible to evaluate available names through global.json and project.json
• dotnet editor vs remove <project_name> - same

Same for VS Code with vscode editor moniker can manage launch.json/tasks.json files, for example adding .net core launch configuration with entry point set up, build, launch tasks, etc

[shaunluttin]

Related StackOverflow question: http://stackoverflow.com/questions/40387332/add-a-project-json-based-project-to-a-sln-file-without-using-visual-studio

[TheSamsterZA]

@blackdwarf Here's a quick mind dump of what I think the dotnet sln command should be capable of doing:

• Please don't forget other project types (vbproj, dbproj, sqlproj, filesystem-based website projects, etc.). The xproj projects should be skipped with info about migrating to csproj.
• Add a way to set the default (startup) project(s):

dotnet sln default <project-name>

and:

dotnet sln create --file <solution-name> --default <project-name>

• It would also be nice to be able to add solution-level items, like so:

  dotnet sln add --file path/to/somefile.ext

Thoughts?

[blackdwarf]

Tracking issue is dotnet/cli#4746

[sayedihashimi]

@TheSamsterZA

Please don't forget other project types (vbproj, dbproj, sqlproj, filesystem-based website projects, etc.).

Yes it will handle all the MSBuild based project types. For website project, how important is that for you to be able to add on a mac? I don't think we've considered this yet.

Add a way to set the default (startup) project(s):

Seems like a good idea for integration with dotnet run. From the ASP.NET perspective the scenario is that I have a Web API service that my front end talks to. When I invoke dotnet run it would be good to start both.

[TheSamsterZA]

@sayedihashimi

For website project, how important is that for you to be able to add on a mac? I don't think we've considered this yet.

I think it's important if only so that there is feature parity across platforms. We can do this in VS proper, so the expectation is that the dotnet sln command should be able to do it, too.

Add a way to set the default (startup) project(s):
From the ASP.NET perspective the scenario is that I have a Web API service that my front end talks to. When I invoke dotnet run it would be good to start both.

This is exactly the scenario I was thinking of, so I am certain that having it in dotnet sln would be appreciated by many.

[blackdwarf]

@TheSamsterZA for the first question, we don't plan to restrict any project. We will focus on supporting .NET Core projects in the first turn of the crank, so to speak, but we will be adding more later as community requests. Also, since CLI is cross-platform, this will work on a Mac as well.

Refresh my memory please, is website project a regular *proj file?

@sayedihashimi I think the startup projects are defined in the *.suo files not sln files, right?

[TheRealPiotrP]

To echo what @blackdwarf says, CLI is x-plat first. If you see any of these capabilities behave better on Windows please do file issues! The Azure Website project template may be Windows focused, but the tools you use to interact with it won't be :)

[sayedihashimi]

@blackdwarf

Refresh my memory please, is website project a regular *proj file?

Website project doesn't have a project file.

@sayedihashimi I think the startup projects are defined in the *.suo files not sln files, right?

Correct.

In VS I can set multiple startup projects and then run/debug them all at once. This is especially important for ASP.NET developers because often times they have multiple web projects (i.e. web api service with a web front end).

I like the suggestion for dotnet sln to support setting startup projects, and then for dotnet run to be able to consume that, if we add support for passing a .sln file to dotnet run. The alternative would be to have dotnet run support multiple projects, but it's annoying to have to pass in extra parameters each time. Also if there are other consumers of the startup project concept (i.e. debugging/profiling/anything that runs the app) would also need similar parameters. The fact that the data is stored in the .suo file instead of the .sln file I don't believe is important here. To the user it's part of "the solution".

I think there is another scenario here that is not typically top of mind. The developer who works in VS and in the command line on the same box. In VS if I set a startup project for a solution, when I invoke dotnet run my.sln I expect it to launch the startup project. Accordingly, if I set multiple startup projects, when I drop to the command line I expect them all to launch just like they would have in VS.

[sayedihashimi]

@piotrpMSFT he's asking about "Website project", it doesn't have anything to do with Azure and is not windows specific.

I do agree with @TheSamsterZA that we should be able to do the same things across tools, but for website project I'm really not sure in this case. Since website project doesn't have a project file the properties are stored in the .sln file. For example here is a snippet from a .sln that contains a reference to a standard .csproj and a website project.

Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "WebApplication7", "WebApplication7\WebApplication7.csproj", "{ECE2722A-3E9A-4DEF-990D-B6AB8EA45DB1}"
EndProject

Project("{E24C65DC-7377-472B-9ABA-BC803B73C61A}") = "WebSite1(1)", "..\..\WebSites\WebSite1\", "{6F02EDA7-411B-4577-BF09-D19BA8021566}"
    ProjectSection(WebsiteProperties) = preProject
        TargetFrameworkMoniker = ".NETFramework,Version%3Dv4.5.2"
        Debug.AspNetCompiler.VirtualPath = "/localhost_7532"
        Debug.AspNetCompiler.PhysicalPath = "..\..\WebSites\WebSite1\"
        Debug.AspNetCompiler.TargetPath = "PrecompiledWeb\localhost_7532\"
        Debug.AspNetCompiler.Updateable = "true"
        Debug.AspNetCompiler.ForceOverwrite = "true"
        Debug.AspNetCompiler.FixedNames = "false"
        Debug.AspNetCompiler.Debug = "True"
        Release.AspNetCompiler.VirtualPath = "/localhost_7532"
        Release.AspNetCompiler.PhysicalPath = "..\..\WebSites\WebSite1\"
        Release.AspNetCompiler.TargetPath = "PrecompiledWeb\localhost_7532\"
        Release.AspNetCompiler.Updateable = "true"
        Release.AspNetCompiler.ForceOverwrite = "true"
        Release.AspNetCompiler.FixedNames = "false"
        Release.AspNetCompiler.Debug = "False"
        VWDPort = "7532"
        SlnRelativePath = "..\..\WebSites\WebSite1\"
        DefaultWebSiteLanguage = "Visual C#"
    EndProjectSection
EndProject

As you can see you cannot just "add a website project" to a .sln, it must be defined. VS also hooks up IIS Express, sets the target fx, etc.

For dotnet sln I think it makes sense to be able to remove a website project from a solution.
For dotnet run I think it make sense to be able to run a website project

Also in addition to this, I've been discussing with @BillHiebert how we can replace the website project with a new project type that is based on ASP.NET Core project type. The idea is that we could have a "Static Web Project" type where you have a pointer to a folder and we handle launching IIS Express and other goodness. If we are able to do that I'd like to see if we can migrate website project users to that new model.

[TheSamsterZA]

@sayedihashimi

I like the suggestion for dotnet sln to support setting startup projects, and then for dotnet run to be able to consume that, if we add support for passing a .sln file to dotnet run.

The fact that the data is stored in the .suo file instead of the .sln file I don't believe is important here. To the user it's part of "the solution".

Agreed. It would be best to place at least the startup project(s) info in the human-readable .sln file instead of the (I believe) binary .suo file. Personally, I would prefer not to have to think about a file that I have no real control over that somehow affects my solution.

[TheSamsterZA]

@sayedihashimi

I just saw this:

Visual Studio Extension: Folder To Solution Folder (GitHub)

Which reminded me of this:

It would also be nice to be able to add solution-level items, like so:
dotnet sln add --file path/to/somefile.ext

To flesh this out a bit more, I would expect dotnet sln add --file some/deep/path/to/somefile.ext to either:

(a) add the to/ folder as a solution-level folder and somefile.ext below it (does the same thing as the Visual Studio Extension: Folder To Solution Folder), or

(b) add the entire folder structure as nested solution sub-folders, with somefile.ext at the very end.

I'd personally prefer (a), though I don't have a strong opinion either way.

There should also be a way to determine the actual absolute path of a given solution-level item, since that is just a reference to some path on disk and does not necessarily live off the solution folder.

[blackdwarf]

All of the above are good scearios, and it is good to see interest in this capability. However, I would like us to focus, obviously, on basic scenarios first (adding .NET Core projects to the solution file). When this is baked, I would look at other scenarios, like adding a solution folders. Similar can be said for website projects, especially since they don't seem to have a *proj file (thanks @sayedihashimi for the info, I haven't used those in a long while :)). Hope this makes sense.

Now, for setting the startup project, I'm still confused. If currently the piece of data that indicates that is in a suo file, how can the CLI keep it in the SLN file? Is there even support for that in the SLN file?

[TheSamsterZA]

@blackdwarf I agree with you that the basic scenarios should be enabled and baked first before enhancing the tool to support more complex scenarios.

However, I do believe there should be some support for solution-level folders as a basic scenario, because one popular structure for .NET projects is:

So if I didn't have a solution file in there and ran

dotnet sln create --file SuperAwesomeThing.sln

I would expect the solution file to add the projects under src and test as solution-level folders:

The same goes for adding a project to an already-existing solution file:

dotnet sln add "project-folder/project-file.ext"

• if the path to the project folder is at the same level as the solution file, add the project directly to the solution.

• if the path to the project folder is in a sub-folder relative to the solution file, add the project to the appropriate solution-level folder.

• if the path to the project folder is in a completely different directory structure relative to the solution file, then just add the project directly to the solution.

What do you think?

[TheSamsterZA]

For startup projects, currently, this information is stored in the .suo file. I would like this information to be stored in the .sln file instead.

Generally, by default the first project added to the solution is marked as the startup project. However, if I want to specify another project (or projects), I would do that with:

dotnet sln default <project-name>

Then, as @sayedihashimi mentioned before, invoking dotnet run would run all startup projects.

[blackdwarf]

@TheSamsterZA for the startup projects, I see what you mean, but unfortunately, changing the behavior of where startup project data is kept should come first from Visual Studio and then flow to the CLI and other tools. There needs to be unification on where this data is kept and not forking based on the toolset which can lead to some confusing situations.

[TheRealPiotrP]

@blackdwarf, I think the mini-spec above is out of date with the design we landed on. Can you update?

It would also be good to open another issue for the globbing approach that @TheSamsterZA is suggesting. Let's not track both here.

[jgoshi]

I completed the implementation for dotnet add|list|remove project

[ArturKarbone]

@shaunluttin just answered your stack overflow question http://stackoverflow.com/questions/40387332/add-a-project-json-based-project-to-a-sln-file-without-using-visual-studio/42735746#42735746