Build the app separately from libraries and tests to drop the -m:1 build workaround

[jschick04]

Summary

This branch unblocks native multi-architecture (x64 + ARM64) builds with three related changes:

1. Removes the -m:1 (single-process MSBuild) workaround from the PR build by fixing the parallel-build race it masked.
2. Adds native ARM64 build support for the C++/WinRT Explorer shell extension.
3. Makes the app's native shell-extension architecture selection architecture-correct (and guards against an arch mismatch inside one MSIX).

1. Drop the -m:1 build workaround

When the whole solution builds in parallel, the MAUI Windows app evaluates the shared libs with a different build dimension (it resolves win-x64) than the tests (AnyCPU), so MSBuild compiles the same lib in two worker processes into the same obj -> intermittent CSC CS2012 ("dll being used by another process") and MSB3030 ("could not copy pdb"). -m:1 masked it by serializing (slow).

Fix: build the MAUI app separately from the libraries and tests.

• New LibrariesAndTests.slnf solution filter (all projects except the app) builds in parallel - uniform AnyCPU, no divergence, no race.
• The app builds in its own step, after the tests.

This is the documented MAUI "build the app separately" pattern. -graphBuild was ruled out (it crashes the WinUI XAML compiler with MSB4166).

2. Native ARM64 build support

The C++/WinRT shell extension (EventLogExpert.ExplorerExtensionNative.vcxproj) was x64-only. This adds:

• Debug|ARM64 + Release|ARM64 ProjectConfigurations mirroring the x64 ones (x64 byte-identical; CETCompat omitted on ARM64 as it is x64/Intel-only).
• Microsoft.Windows.SDK.CPP.arm64 in packages.config at the same version as the .x64 package, with an $(Platform)-conditional import.
• In the app EventLogExpert.csproj: a win-arm64 -> ARM64 native-platform mapping and a per-arch vswhere requirement that adds VC.Tools.ARM64 only on the ARM64 pass.

A throwaway CI spike confirmed the native extension cross-compiles to ARM64 on the windows-2022 toolchain (dumpbin reported an AA64 machine type).

3. Architecture-correct native-platform selection

ExplorerExtensionNativePlatform was derived only from RuntimeIdentifier, so a build that sets Platform=ARM64 with no RID (e.g. a Visual Studio ARM64 MSIX build) would package an arm64 ElevationHelper next to an x64 native DLL in one MSIX. The derivation now also honors Platform=ARM64 (matching the existing _ElevationHelperRid precedence: RID wins, then Platform=ARM64, then x64), and a build-time consistency guard fails the build if the native platform and the ElevationHelper RID ever disagree on architecture.

Cleanup: remove empty placeholder integration test suites

This also removes three integration test projects that contained no tests, only scaffolding (auto-generated GlobalUsings / xunit entry point, and in one case an unused fixture): EventLogExpert.EventDbTool.IntegrationTests, EventLogExpert.Filtering.IntegrationTests, and EventLogExpert.UI.IntegrationTests. They are dead scaffolding - the UI assembly was renamed to Runtime (so EventLogExpert.Runtime.IntegrationTests covers it), and the EventDbTool/Filtering integration coverage lives in the Runtime / DatabaseTools / Provider.Database integration suites. Nothing references them; they are removed from EventLogExpert.slnx and LibrariesAndTests.slnf. No test coverage is lost (there were no tests to lose).

Validation

• The libs+tests filter builds cleanly; the parallel race no longer reproduces.
• The native ARM64 build was CI-proven on a dedicated build spike (the native extension cross-compiled to ARM64; dumpbin reported an AA64 machine type).
• The native-platform derivation was verified with a dotnet msbuild -getProperty truth table across the (RID, Platform) matrix; the consistency guard fires only on a genuine mismatch.
• This PR's windows-2022 CI validates the managed parallel build and all tests. It does NOT build the native C++/WinRT extension or the MSIX package: the Build app step is a plain dotnet build (no WindowsPackageType=MSIX), so the BuildExplorerExtensionNative target does not run. The native/MSIX path is validated separately by the release pipeline and the ARM64 build spike.

Notes

• Adding a new test project requires adding it to LibrariesAndTests.slnf; if forgotten, the test step fails loudly (dotnet test --no-build on an unbuilt project), so it is self-correcting.
• A companion change removes -m:1 from the OneBranch release pipeline build step; it lands after this merges.

[Copilot]

Pull request overview

This PR removes the -m:1 single-node MSBuild workaround by eliminating the underlying parallel-build PDB copy race: it switches the repo to embedded debug symbols (so no separate .pdb files need to be copied) and enables CI-only deterministic build behavior via ContinuousIntegrationBuild.

Changes:

• Set repo-wide <DebugType>embedded</DebugType> to avoid parallel-build .pdb copy races.
• Enable <ContinuousIntegrationBuild>true</ContinuousIntegrationBuild> when running on Azure Pipelines (TF_BUILD) or GitHub Actions (GITHUB_ACTIONS).
• Update PR CI workflow to build without -m:1, allowing parallel builds again.

Reviewed changes

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

File	Description
Directory.Build.props	Sets embedded debug symbols repo-wide and enables CI-only deterministic builds via ContinuousIntegrationBuild.
.github/workflows/PullRequest.yml	Drops the -m:1 build flag so CI uses parallel MSBuild again.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 15 out of 15 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 15 out of 15 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

tests/Integration/EventLogExpert.EventDbTool.IntegrationTests/EventLogExpert.EventDbTool.IntegrationTests.csproj:1

• This change removes the EventDbTool integration test project, but repo tooling still expects it to exist: compose.yml defines an eventdbtool service that runs tests/Integration/EventLogExpert.EventDbTool.IntegrationTests/EventLogExpert.EventDbTool.IntegrationTests.csproj, and tests/Integration/README.md documents running that suite via Docker Compose. With the project deleted, those local workflows will fail (missing csproj). If the suite is being retired, the Compose + docs (and any scripts) should be updated in the same PR; otherwise the project should be restored.

[Copilot]

Pull request overview

Copilot reviewed 15 out of 15 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 17 out of 17 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

Copilot reviewed 50 out of 50 changed files in this pull request and generated 2 comments.