dotnet build should work on a folder with global.json

[Sridhar-MS]

It should build all the project folders configured in global.json.

[blackdwarf]

@Sridhar-MS agreed, this would be good.

@cdmihai thoughts?

/cc @piotrpMSFT

[cdmihai]

This means that there should also be one lock file for the global.json that resolves the dependencies for all the projects visitable from global.json. Otherwise build can't walk the project dependencies and topo sort them.

Also, wouldn't other dotnet verbs also need to be able to function with a global.json? Like restore, pack, test, etc. If yes, dotnet CLI would need to have a shared mechanism for this.

What the shared component could do is:

• get all projects visitable from global.json
• find the root projects
• create am empty meta project that references the root
• return this meta project so it can be restored, packed, tested, built, etc

[olivier-spinelli]

Since the global.json references necessarily local projects, do we actually need the full dependencies analysis and topo sort?
My thoughts is that a rather quick analysis of the project.json files (without diving into their external dependencies) should be enough to topologically sort only the local projects.
Based on this ordering, the "global" command (whatever it is) could be (blindly) applied onto the different local projects... in order.

Do I miss something.?

[cdmihai]

Unfortunately you cannot visit all the projects by only recursively traversing the local project.jsons, for several reasons:

• CLI's project model is built from lock files, and build heavily uses the project model.
• AFAIK (@davidfowl), you can have Nuget packages depending on a project (when you replace a nuget package with its sources). This type of dependency is only discoverable from a lock file.

Ideally global jsons should aggregate cohesive projects that are meant to work together on the same resolved dependency DAG. Otherwise you get weird issue. For example, when two lock cones under the same global.json share the same project A. A depends on package X. In one cone, X is resolved to one version, and in the other cone X is resolved to another version. Should the compilation of a A on one cone now invalidate a previous compilation of A from a different cone? Should we compile A for each cone?
Not having a lock file for a global json gets us into all sorts of issues like these.

[smbecker]

You can do dotnet build **/project.json

[kaspersorensen]

+1 for builds based on global.json! We're currently trying to automate dotnet core builds and having to deal with the dependencies and orders of individual project.json files seems like really not the way to go.

[plioi]

Is there any downside to what @smbecker suggests? I'm currently finding-and-invoking the latest msbuild using the same technique seen here: https://github.com/jbogard/MediatR/blob/e7a6644fe14eac58a144004467568c7115c7c2ba/Build.ps1

If the suggestion above is truly equivalent, that'd save a lot of noise from my build process.

[kaspersorensen]

I think the downsides are:

• No way to define the order of the modules/folders to build
• No way to exclude certain modules/folders that may not be relevant or even desired.

[smbecker]

I have found that order is somewhat irrelevant when doing it as I suggested. Either that or the CLI figures it out at runtime because I haven't had any issues with ordering. I believe that it supports multiple directory selectors and various glob patterns that you could likely get your desired inclusion/exclusion rules.

[bojingo]

+1, especially the comment about other dotnet commands (dreaming of dotnet test at global.json level!)

[TheRealPiotrP]

The team is actively working on enabling MSBuild and the component affected will be superseded by the new project system, so I am closing this issue.