[Feature Request]: Add ability to build multiple projects on the command line without sln or slnf

[LostTime76]

Summary

I would like to know the background story of why this is not possible to do today and figured I would ask if it was possible to make this happen.

Background and Motivation

Solution files...................

Today I can build multiple projects with dotnet build by passing in a solution or solution filter to specify the projects I want to build. Additionally, I have the ability to build a single project without a sln or slnf by passing in the name of the project directly. Therefore, it seems like there is no limitation on building multiple projects in a single dotnet build call.

The only reason I have had to create solution files is so that I can have the ability to build multiple related projects at a time. That's it, they do nothing more and they clutter the file tree. Recently, I have had to be able to 'select' individual projects or groups of projects to build within a file tree. This has led me to solution filters, which feel like a cludge over already crusty solution files.

Furthermore, I can invoke the MSBuild task within a project file and pass to it an item list of projects to build! This further solidifies my belief that there is no limitation of building without solution files.

Proposed Feature

Add the ability to pass a list of projects to the dotnet cli / msbuild cli to build without a solution file instead of being limited by a single project input. I think this would get rid of the requirement for many people to need solution files. It can make build automation and selecting the projects to build much easier by allowing them just to be specified on the command line directly.

Proposal(s):

1. Allow the user to specify multiple project paths on the command line in the invocation. This would just be an extended feature of the existing command line.
2. If (1) is not possible, provide a new command line option for specifying multiple projects. The 'how' is not important. Could be a single option delimited by a special character or a repeated option such as: "-proj proj1path.proj -proj proj2path.proj"

Alternative Designs

No response

[naeemaei]

Can I work on this feature?

[baronfel]

This seems like a logical and natural extension of the existing MSBuild CLI Grammar - we'd love to see a pull request in this space!

There are a few things to think about here:

• There are multiple ways to specify a project - either explicitly via passing project files as command line arguments or implicitly discovering a project from the current working directory. We should define how the build should behave when 'implicit discovery' occurs
  • Proposal: any change to allow multiple projects should only apply when multiple projects are provided directly on the command line - there should be no change to implicit discovery.
• MSbuild can accept .binlog files as an input - this allows for 'replaying' a previous build, often with different loggers/analysis enabled. We should define how the build would run if both binlog inputs and project files were specified.
  • Proposal: if both .binlog and project files are specified at the command line, an error should be thrown instructing the user to provide only a single binlog file or one or more project files.
• MSbuild can accept solution files, solution filters, and project files on the command line. We should define what the expected behavior is when combinations of these types of files are specified.
  • Proposal: Only multiple project files should be allowed to be passed - multiple solutions or solution filters, and combinations of solutions/solution filters/project files should raise an error saying that only multiple project files are allowed to be passed to MSbuild.
    • Reasoning: solutions and solution filters are converted to a 'metaproject' with a lot of implicit behaviors that don't directly align to project-file-based usage of MSBuild - it is unclear how to reasonable combine/merge these different kinds of inputs.

Useful links

• here is where the project argument is defined - this will likely need to be changed to remove the DuplicateSwitchError and allow multi params

[baronfel]

@naeemaei I realized I forgot to @ you directly - if you'd like to contribute this feature we'd love to help you implement it!

[naeemaei]

@baronfel Yes, I'd like to contribute.