Background
AppxLooseLayoutDeployment derives both the MSIX package name and the execution alias from the layout directory, so two checkouts can run the packaged tier concurrently without evicting each other. See TESTING.md — "The registered identity is per-checkout".
Introduced in #1260.
The gap
The automated tests prove the derivation is distinct: different layouts produce different package names and different alias stubs, and one layout is stable across reruns (WorktreeIdentityTests, PackagedHarnessTests).
They do not prove Windows then keeps two such registrations and two alias stubs alive at the same time. Every automated tier registers exactly one package per run, so nothing exercises coexistence. Two failure modes are therefore invisible to CI:
- A second registration evicts the first despite the distinct identity, leaving the first run either dead or silently exercising the wrong binary.
- Both alias stubs land but one wins the
%LOCALAPPDATA%\Microsoft\WindowsApps name, so the tier launches the other checkout's host.
Both are exactly what the derivation exists to prevent, and both are machine-level behaviour that only a real two-package registration can observe.
Current mitigation
A repeatable manual procedure is documented in TESTING.md under "Verifying coexistence by hand" — roughly ten minutes, needs Developer Mode and a second checkout. Run it when the derivation or the registration path changes.
What would close this
Either of:
-
An integration test that registers two layouts at once and asserts two packages with distinct InstallLocations plus two alias stubs. The obstacle is cost and environment: the layout is ~242 MB / 387 files, so a second copy is not free, and registration needs Developer Mode, which not every runner or dev machine has. A test that quietly skips when it cannot register would be indistinguishable from one that passes, so it needs a real gate with a visible verdict.
-
Making the manual check a required release gate, run and recorded before publishing.
Worth noting the concurrent case is the interesting one. Sequential registration can pass while concurrent registration does not, so any automated version must overlap the two registrations rather than serialize them.
Context
Raised by Copilot review on #1260: "These tests deliberately stop before the machine-level behavior the change is meant to guarantee: two rewritten loose layouts are never registered together and both derived aliases are never launched."
Background
AppxLooseLayoutDeploymentderives both the MSIX package name and the execution alias from the layout directory, so two checkouts can run the packaged tier concurrently without evicting each other. SeeTESTING.md— "The registered identity is per-checkout".Introduced in #1260.
The gap
The automated tests prove the derivation is distinct: different layouts produce different package names and different alias stubs, and one layout is stable across reruns (
WorktreeIdentityTests,PackagedHarnessTests).They do not prove Windows then keeps two such registrations and two alias stubs alive at the same time. Every automated tier registers exactly one package per run, so nothing exercises coexistence. Two failure modes are therefore invisible to CI:
%LOCALAPPDATA%\Microsoft\WindowsAppsname, so the tier launches the other checkout's host.Both are exactly what the derivation exists to prevent, and both are machine-level behaviour that only a real two-package registration can observe.
Current mitigation
A repeatable manual procedure is documented in
TESTING.mdunder "Verifying coexistence by hand" — roughly ten minutes, needs Developer Mode and a second checkout. Run it when the derivation or the registration path changes.What would close this
Either of:
An integration test that registers two layouts at once and asserts two packages with distinct
InstallLocations plus two alias stubs. The obstacle is cost and environment: the layout is ~242 MB / 387 files, so a second copy is not free, and registration needs Developer Mode, which not every runner or dev machine has. A test that quietly skips when it cannot register would be indistinguishable from one that passes, so it needs a real gate with a visible verdict.Making the manual check a required release gate, run and recorded before publishing.
Worth noting the concurrent case is the interesting one. Sequential registration can pass while concurrent registration does not, so any automated version must overlap the two registrations rather than serialize them.
Context
Raised by Copilot review on #1260: "These tests deliberately stop before the machine-level behavior the change is meant to guarantee: two rewritten loose layouts are never registered together and both derived aliases are never launched."