Feature Query API

[surayya-MS]

Fixes #9653

Context

We need an API that can tell us whether a specific feature is available or not.

Changes Made

Added a new API

namespace Microsoft.Build.Framework
{
    public static class Features
    {
        public static FeatureStatus CheckFeatureAvailability(string featureName) 
        {
        }
    }

    public enum FeatureStatus
    {
        Undefined,
        Available,
        NotAvailable,
        Preview,
    }
}

Usage example:

// Available, NotAvailable or NotFound
var availability = Features.CheckFeatureAvailability("Feauture1");

Command-line support

for switches /featureavailability and /fa.

Similar to /version switch, if featureavailability switch is detected then ignores other switches. /version switch has higher priority than featureavailability.

There is no logo shown when /featureavailability is detected (similar to /getProperty).

PS>msbuild /fa:Feature1
Available

PS>msbuild /featureavailability:Feauture2
Undefined

PS>msbuild /featureavailability:Feauture1,test /fa:Feature2
{
  "Feature1": "Available",
  "test": "Undefined",
  "Feature2": "NotAvailable"
}

PS>msbuild /fa:
MSBUILD : error MSB1067: Must provide a feature name for the featureavailability switch.
    Full command line: 'msbuild /fa'
  Switches appended by response files:
Switch: /fa

For switch syntax, type "MSBuild -help"

Property Function CheckFeatureAvailability

string CheckFeatureAvailability(string featureName)

The result is one of "Undefined", "Available", "NotAvailable" strings.

Usage Example:
$([MSBuild]::CheckFeatureAvailability(Feature1))

Testing

Manual and unit tests.

Notes

[ladipro]

If we go with the command-line support (does it map to a known requirement or is it for completeness/future-proofing?), I think it would be useful to support asking for several or all features with one invocation. The getProperty switch is prior art - it prints just the value when asking for one, and JSON-formatted output when asking for many.

[surayya-MS]

If we go with the command-line support (does it map to a known requirement or is it for completeness/future-proofing?), I think it would be useful to support asking for several or all features with one invocation. The getProperty switch is prior art - it prints just the value when asking for one, and JSON-formatted output when asking for many.

There are no requirements for command-line support yet, I implemented it for completeness, and might remove it later from the PR. Thanks for suggestion! I agree it is more consistent the way you described. I'll change it to support asking for multiple features.

[ladipro]

We could also expose the new functionality as a property function. This would make it available to project files, and via switches like getProperty also to command line, without having to add a new command line switch.

I think we'd want to get @baronfel's feedback here. The requirements would be met with a programmatic API for MSBuild hosts (e.g. IDEs) but it's definitely useful to explore additional angles. Thank you!

[baronfel]

I agree with Ladi - we should ensure an easy way to check feature enablement at all points that MSBuild can be extended/consumed:

• CLI (done)
• API (covers loggers, in-process evaluation/execution)
• Property Functions (covers various props/targets based extension)

[JanKrivanek]

Good job!

[ladipro]

New command line switches should be added to help output (msbuild -h, dotnet msbuild -h). Probably ok merging as is, as long as we don't forget to add them as part of fixing #9710.