Collection Expression like condition syntax (with `in` / `not in` csharp-y idioms)

[am11]

Summary

Introduce support for collection-based condition expressions in MSBuild, such as $(TargetOS) not in ['browser', 'haiku', 'illumos'], to simplify and clarify multi-value comparisons.

Background and Motivation

MSBuild currently requires verbose chaining of and/or conditions to check if a property matches (or doesn't match) a set of values. This becomes unwieldy and error-prone, especially in cross-platform builds or SDK logic where exclusion lists are common.

Example today:

Condition="'$(TargetOS)' != 'browser' and '$(TargetOS)' != 'haiku' and '$(TargetOS)' != 'illumos' and '$(TargetOS)' != 'netbsd' and '$(TargetOS)' != 'solaris'"

This is hard to read, maintain, and scale.

There are several cases in the runtime repo (e.g., this one) where this change can significantly reduce code length.

Proposed Feature

Enable syntax like:

Condition="'$(TargetOS)' not in ['browser', 'haiku', 'illumos', 'netbsd', 'solaris']"

or:

Condition="!['browser', 'haiku', 'illumos', 'netbsd', 'solaris'].Contains('$(TargetOS)')"

This would improve clarity and reduce duplication in build logic.

Alternative Designs

Allow item groups in conditions with .Contains():

<ItemGroup>
  <UnsupportedOS Include="browser;haiku;illumos;netbsd;solaris" />
</ItemGroup>

<PropertyGroup>
  <_NativeAotSupportedOS Condition="!@(UnsupportedOS->'%(Identity)').Contains('$(TargetOS)')">true</_NativeAotSupportedOS>
</PropertyGroup>

This works but is verbose and not usable inline in many contexts.

[teo-tsirpanis]

I think a syntax like '$(TargetOS)' not in 'browser;haiku;illumos;netbsd;solaris' (or a property function if we don't want to add new syntax to conditions) is more in line with MSBuild's conventions.

The alternative design is a non-starter, because by design, items are evaluated after properties.

[am11]

Ah, right. Works obviously with first group is in a dependent target. But yes, any succinct syntax would do. Semicolon syntax is already in use so that might complicate it (hard to disambiguate scenarios; I hope not 🤞).