dotnet
[Feature Request]: Extend CLI JSON evaluation to support solutions
Summary
We should extend the CLI evaluation to support solutions, not just projects.
Background and Motivation
In .NET 8 RC2 we added support for a few new flags to make extracting properties, items, and target results from a project easier from the command line:
- -getItem
- -getProperty
- -getTargetResults
These create JSON structures for the requested data, either after evaluation (if no target is specified) or after the specified target is run.
These work great for individual projects, but users expect the feature to work for solutions as well.
Proposed Feature
There are a few ways this could go (not exhaustive):
- allow the existing syntaxes to work against the generated solution metaproject
- apply the existing syntax to each built traversal project in the solution
- ???
I have opinions about which of these I prefer, but we should gather more feedback.
Alternative Designs
No response
cc @jrdodds for comment - what would your expected behavior be when CLI JSON evaluation was invoked against a solution?
I was thinking in terms of
- allow the existing syntaxes to work against the generated solution metaproject
e.g. the following could be used to get the projects in the solution:
msbuild example.sln -getItem:ProjectReference
Getting the list of projects from the solution is a task that comes up (often it is for a validation or reporting need) and I have seen some really terrible approaches. But maybe there should be a GetSolutionProjects function that can return the list of projects for the current MSBuild run and the JSON CLI switches should traverse the projects.
Is this request still considered?
I'd like to evaluate information on the solution level, but there is no elegant way yet as -getItem, -getProperty, -getTargetResults is only supported for projects.
@czdietrich we need to more fully spec out the expected behaviors. What are some specific scenarios you would like to accomplish with the -getX flags? What kinds of solution shapes would you like to support?
My current scenario is to get a set of properties (i.e. AssemblyName, OutputType) from all projects contained in the solution file.
While I could for each through all projects and use -getProperty, it is fairly slow when the amount of projects grow.
My idea was instead to create an MSBuild target on the solution level (via Directory.Solution.targets) and gather all the information there and just return a combined result, which unfortunately is not supported yet.
A simple test showed that using the target on the solution level would take less than 20 seconds for our scenario (~370 projects) and about 2 minutes for calling each project separately.
Though, it is possible to work around that limitation on solution level targets by creating an output file containing the information, but it adds a fair amount of additional work like escaping data and parsing it back and the need for a well known output file path.
The workaround wouldn't probably as complicated, when there was a simple way to serialize ItemGroup items to json strings (at least I'm not aware of this), so data could easily be serialized to a file. But when using -getTargetResults the serialization of ItemGroup items works just out-of-the-box which is nice.
Also something off-topic regarding the dotnet cli, you can just ignore this 😬
I find it a bit unnecessary that dotnet sln [SOLUTION] list returns the following 2 lines in the beginning:
Project(s)
----------
because when you want to automate something in a script, you always need to skip these lines.
Thanks for the scenario. Regarding your off-topic we're investing in machine-readable (JSON) outputs for more dotnet commands over time exactly for reasons like that, so keep an eye out :)
Roslyn has various .slnfs for local development use cases, which we would like to verify in CI are not broken by changes to project structure, but which we don't actually need to build in CI. So, some way to run evaluation on those without needing to build would be handy.
