Refactor MultiTarget scripts for checking component support

[Arlodotexe]

This PR:

• Extracts MultiTarget/WinUI code checks from Build-Toolkit-Components.ps1 into a dedicated script Test-Component-Support.ps1.
• Adds a new script Filter-Supported-Components.ps1 as a one-liner for filtering (or populating) a list of toolkit components based on whether they support the given WinUI and MultiTarget preferences.
  • This is needed to fix workflow issues with incremental component builds over in Labs, see https://github.com/CommunityToolkit/Labs-Windows/actions/runs/15497274118/job/43639235687#step:14:1

[Copilot]

Pull Request Overview

This PR refactors component support checks by extracting WinUI and MultiTarget verifications into separate scripts and adding a filtering script for incremental builds.

• Extracts multi-target support checks from the main build script into Test-Component-Support.ps1.
• Adds a new one-liner script, Filter-Supported-Components.ps1, to filter components by support.
• Updates Get-MultiTargets.ps1 to ignore empty entries and simplifies Build-Toolkit-Components.ps1 by delegating support checks.

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
MultiTarget/Test-Component-Support.ps1	Contains refactored logic for validating component multi-target support and WinUI.
MultiTarget/Get-MultiTargets.ps1	Updates multi-target extraction to filter out empty entries.
MultiTarget/Filter-Supported-Components.ps1	Introduces a new script to filter components based on support criteria.
Build-Toolkit-Components.ps1	Removes duplicated support-check logic and integrates the new Test-Component-Support.ps1.

Comments suppressed due to low confidence (1)

MultiTarget/Test-Component-Support.ps1:109

• The error message references '$MultiTargets', which is not defined in this context; consider changing it to '$RequestedMultiTargets' to accurately reflect the requested targets.

$Reason = "None of the requested MultiTargets '$MultiTargets' are enabled for this component."

[michael-hawker]

The Labs PR which tests this is failing as well.

We may want to investigate some PowerShell tests or something for some of these smaller scripts, not sure how easy it'd be to mock up some projects or something.

[michael-hawker]

Looks like CommunityToolkit/Labs-Windows#681 passed now, just been looking at the output.

Future: realizing it could be nice for some scripts to output more info (like which components changed (Get-Changed-Components), the validated package names, etc...) so that we have a few more easy spots in the CI to see what's happening where.

I saw DependencyInjection went for netstandard (0) step
I saw AppServices and Notifications went with UWP in (2) step but not in (3) - what's the piece which decides where they go?

So, appears good?

[Arlodotexe]

I saw DependencyInjection went for netstandard (0) step I saw AppServices and Notifications went with UWP in (2) step but not in (3) - what's the piece which decides where they go?

AppServices and Notifications don't support any WinUI3-capable MultiTargets, they're UWP only.

Future: realizing it could be nice for some scripts to output more info (like which components changed (Get-Changed-Components), the validated package names, etc...) so that we have a few more easy spots in the CI to see what's happening where.

It's tricky to have additional stdout here, since Actions pipes it to the variables we're setting. We can see the result in the very next step, as input to the Build-Toolkit-Components.ps1 script.