[Extensibility] Fix dual-path backend activation and Compile bucket filtering

[PureWeen]

Note

Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!

Description of Change

This is a focused follow-up to #36654 from GPT-5.6 Sol post-merge verification. It addresses two gaps in the data-driven MauiPlatformSpecificFolder implementation related to #34099.

• Enables one backend registration to activate through either a recognized TargetPlatformIdentifiers match or neutral-TFM MauiActiveBackend selection.
• Prevents the platform Compile removal batch from capturing explicit-false Compile items that happen to exist on disk beside an explicit-true item.

Root causes and behavior

Dual-path backend activation

_MauiNormalizePlatformSpecificFolders previously derived ActivationValue from BackendIdentity only when both singular and plural TPI metadata were empty. A registration such as TargetPlatformIdentifiers="macos" BackendIdentity="macos" therefore worked for a recognized macOS TPI but could not use MauiActiveBackend=macos on a neutral TFM.

The normalization now derives the default whenever ActivationValue is empty, regardless of TPI metadata. Explicit ActivationValue and ActivationProperty values remain untouched. The existing recognized-TPI guard still prevents a neutral selector from over-activating the backend on another recognized TPI.

Compile metadata bucket isolation

_MauiRemovePlatformCompileItems batched on %(Compile.ExcludeFromCurrentConfiguration) but created each batch from a fresh filesystem glob. In the true batch, that glob also discovered physical Compile files belonging to a separate explicit-false metadata bucket, allowing the false item to be removed unless it was separately allow-listed.

Removal candidates now originate from the batched @(Compile) identities and are narrowed to $(PlatformsProjectFolder). Allow-list matching remains path-like, and the operation does not mutate or reorder surviving Compile items.

Tests

Added shipping-target regression coverage in MSBuildTests for:

• one macos registration activating through recognized TPI and neutral MauiActiveBackend paths;
• negative recognized-TPI and nonmatching-backend cases;
• explicit-false and explicit-true physical Compile files without an allow-list, asserting only the true item is removed;
• surviving metadata, ordering, and duplicate count;
• explicit custom activation semantics on a registration that also has TPI metadata.

Validation performed:

• Both new minimal repros fail against merge ff48f228 and pass with this change.
• Workload-neutral real shipping-target matrix passed for legacy shared folders, all built-in mappings, GTK/backend activation, custom activation properties, whitespace/unresolved metadata, bare-ActivationValue compatibility, design-time unflip, ordering, and duplicate counts.
• Target XML validation, diff whitespace validation, and targeted dotnet format --verify-no-changes passed.

The full Controls.Xaml.UnitTests invocation could not run locally because restoring Microsoft.Maui.BuildTasks.slnf requires the unavailable iOS workload (NETSDK1147). The same shipping targets were therefore exercised directly with the repository-pinned .NET 11 SDK and workload-neutral net10.0 repro projects.

Issues Fixed

Related to #34099.
Follow-up to #36654.

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 36956

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 36956"

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

This PR tightens .NET MAUI SingleProject MSBuild extensibility for third-party backends by (1) allowing a single backend registration to activate through either recognized TPI matching or neutral-TFM backend selection, and (2) fixing _MauiRemovePlatformCompileItems so its removal batching can’t incorrectly remove Compile items from other metadata buckets.

Changes:

• Default ActivationValue from BackendIdentity even when TargetPlatformIdentifier(s) metadata is present, enabling dual-path activation.
• Rework _MauiRemovePlatformCompileItems to root removal candidates in the batched @(Compile) identities (instead of a fresh filesystem glob) and then narrow to $(PlatformsProjectFolder).
• Add MSBuild unit test coverage for the compile-removal bucket isolation regression and for dual-path backend activation.

Show a summary per file

File	Description
src/Controls/tests/Xaml.UnitTests/MSBuild/MSBuildTests.cs	Adds regression tests covering compile-removal bucket isolation and dual-path backend activation behavior.
src/Controls/src/Build.Tasks/nuget/buildTransitive/netstandard2.0/Microsoft.Maui.Controls.SingleProject.targets	Fixes compile removal candidate selection to respect cross-item-type batching buckets and avoid filesystem-glob cross-contamination.
src/Controls/src/Build.Tasks/nuget/buildTransitive/netstandard2.0/Microsoft.Maui.Controls.SingleProject.Before.targets	Updates backend activation defaulting logic so one registration can activate via recognized TPI or neutral MauiActiveBackend.

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 1

[kubaflo]

Closing in favor of #36957. Main build 1533723 fails the PR-added SingleProject_RemovePlatformCompileItems_RemovesOnlyCompileItemsMarkedTrue test on every Windows Helix XAML leg: the explicit-false marker is removed. #36957 is the selected implementation and carries the final expanded coverage.