Add MAUI ApplicationArtifact metadata for net11p6

[Redth]

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!

Summary

Aligns .NET MAUI with the shared platform @(ApplicationArtifact) contract for the net11p6 release.

MAUI does not calculate platform artifact paths or create a parallel MAUI artifact item group. Instead, MAUI appends _AddMauiApplicationArtifactMetadata to $(GetApplicationArtifactsDependsOn) and updates existing platform-produced @(ApplicationArtifact) items with MAUI project metadata:

• ApplicationId
• ApplicationIdGuid
• ApplicationName from ApplicationTitle
• ApplicationTitle
• ApplicationDisplayVersion
• ApplicationVersion

Platform dependencies

This PR depends on the platform SDK @(ApplicationArtifact) producers landing first for net11p6:

• Android: Expose Android package output items android#11674
• iOS/MacCatalyst/macOS/tvOS (dotnet/macios): Expose application artifacts macios#25723

Those platform changes, or equivalent follow-up PRs if the linked PRs are superseded, need to be merged and flow into net11p6 before this MAUI change is useful end-to-end. The platform SDKs remain the source of truth for artifact identity, path, package format, and platform-specific metadata; MAUI only enriches those existing items.

[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 -- 35973

Or

• Run remotely in PowerShell:

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

[kubaflo]

Multi-Model Review — PR #35973

Verdict: ❌ NEEDS_CHANGES
Confidence: High (unanimous across all 4 models)

All 4 models independently identified issues that should be addressed before merging.

Model agreement: gemini (NEEDS_CHANGES/1), gpt-5.5 (NEEDS_CHANGES/1), opus-4.6 (NEEDS_CHANGES/1), opus-4.8 (NEEDS_CHANGES/2)

Findings: 4 unique issues identified.

[kubaflo]

The relative path $(MSBuildThisFileDirectory)..\..\..\ assumes the test directory is located within the MAUI repository bin/ folder. However, on Azure Pipelines CI, TestDirectory is located under AGENT_TEMPDIRECTORY (e.g., .../test-dir/ApplicationArtifactsAreEnrichedWithMauiMetadata/). As a result, traversing up 3 directories points to AGENT_TEMPDIRECTORY/src/Workload/... instead of the repository, causing MSB4019 missing import errors and failing the integration tests.

[kubaflo]

This import is rooted at the generated test project's MSBuildThisFileDirectory and walks up three directories to find src/Workload. That happens to work for local fallback TestDirectory under the repo's bin/test-dir, but in Azure Pipelines TestEnvironment.GetTestDirectoryRoot() uses AGENT_TEMPDIRECTORY/test-dir, so ......\src does not point at the MAUI checkout and the new Build integration test cannot import Microsoft.Maui.Sdk.After.targets. The current CI failures in the Build integration lanes are consistent with this PR-introduced test path issue.

(found by: 5, 4)

[kubaflo]

The explicit <Import Project="$([System.IO.Path]::GetFullPath('$(MSBuildThisFileDirectory)..\\..\\..\\src\\Workload\\...'))" /> assumes the project directory is 3 levels deep inside the repo root. Locally this resolves from <repo>/bin/test-dir/<testname>/ to <repo>/. In CI, TestDirectory is under $AGENT_TEMPDIRECTORY/test-dir/<testname>/, so 3 parent traversals land in the agent temp directory—not the repo. The targets file won't exist there, causing a build error. This is the likely cause of the CI 'Build integration tests' failures on both macOS and Windows.

[kubaflo]

Both WriteGetApplicationArtifactsMetadata and WritePublishApplicationArtifactsMetadata depend directly on SeedApplicationArtifacts;_AddMauiApplicationArtifactMetadata, so they exercise the metadata target in isolation rather than through a real GetApplicationArtifacts/Publish invocation; the actual wiring is only checked indirectly by the string Assert.Contains on the depends-on file (line 178). The Publish variant therefore adds no coverage beyond the Get variant. This is understandable while the platform GetApplicationArtifacts target is unavailable in net11, but consider collapsing the duplicate target (or asserting the real wiring) once the platform producers land.