[Built-in analyzer] MSBuild task with BuildInParallel is batched

[ladipro]

Background

This issue tracks one of the BuildCheck analyzers we would like to ship in-box with MSBuild.

Goal

Implement an analyzer with the following rule: The MSBuild task is not executed batched when the BuildInParallel parameter is true.

Notes

The intention of BuildInParallel = true is to run child builds in parallel. Batching the task, on the other hand, makes it run in a loop, one invocation at a time, which is likely not desired.

[rainersigwald]

Note that this will have to allow some batching, for instance the way RPR does it today (it batches in such a way that each batch could have multiple items in it). The ideal catch would be "the computed batches are one per item" or something. That is, batching on %(Foo.Identity) is bad but other metadata may be ok.

[sharwell]

I think the first step here is understanding cases in the wild where this would be a "true positive". There are more heuristics involved than I would normally like to see for a deterministic analyzer, so if the number of actual cases where it matters are uncommon, perhaps it would be best to defer this rule?

[yuehuang010]

I would ask a generalize feature. Add feature for task author indicate and error when the Task is batched into two more instances. In C++ case, Link task should have one call. But sometimes, due to bad target authoring with metadata, it is divided and it is hard to detect.

This could also apply to CSC too.

[KalleOlaviNiemitalo]

In C++ case, Link task should have one call.

Don't you need a Link call for each language when building MUI resource DLLs?

[yuehuang010]

C++ Resource tooling would have a separate project for resource dll, then use MSBuild project batching to call each one with a different property for language.

[baronfel]

related: we should flag when a single item + batching is used (i.e. in this per-TFM-walking Target). The suggestion here should be to move to precomputing the item lists and parallelizing.