Choose/When/Otherwise in Targets

[dasMulli]

<Choose>/<When>/<Otherwise> is a nice feature that allows replacing complex conditions with what is effectively a switch-case-default but can only be used on the project level and not within targets.

Can this be changed to work within targets?
This would theoretically conflict with tasks being named Choose, are there any ways to deal with this? - like (and I feel bad suggesting this) optional xml namespace for <MSBuild:Choose> and prefer a task named Choose if defined.

[dasMulli]

@rainersigwald @jeffkl @cdmihai is this feasible at all?
I so, I'd hope to see this in 16.0. If not, go ahead and close it as "won't implement".

[rainersigwald]

I don't have a strong objection to this, other than the conflict-with-task one. But it's not very high on my priority list, personally. Anybody else feel more strongly about it?

[cdmihai]

Implementation wise it will be interesting, since the current design accepts only tasks within targets (properties and items in targets are actually implemented as tasks). But shouldn't be too hard, probably involves implementing a Choose IntrinsicTask .

[dasMulli]

Implementing a choose intrinsic task seems to be promising, I got a prototype at
https://github.com/dasMulli/msbuild/tree/feature/choose-in-targets (Compare)

If there is interest in taking this as a community contribution I could invest more work into it.

[cdmihai]

Took a quick look over it and looks good! Feel free to open it up as a WIP PR to get more feedback.

My take on it:

• not sure whether to allow task executions, or to restrict it to only what's allowed in the choose elements outside of targets.
• add more tests. To find the relevant tests to duplicate (or transform them into [Theory]) you can search for <choose in all the *_Tests.cs files. But do send the WIP PR before you do this.

[rainersigwald]

Team triage: #3851 is a solid-looking implementation of this, but we currently think we should wait for a major release to add this type of language feature. If we want to take this for 17.0, it should definitely start with reviving #3851.

[voroninp]

Hello there ;-), what's the curent status of this issue?