desktop:ExecutionAlias declared in Package.appxmanifest not working on Windows Server 2019

[HO-COOH]

Describe the bug

A few users of my app reported that they cannot launch my app on their Windows Server. After some digging, I found on normal Windows 10/11, if the app declares an desktop:ExecutionAlias, it will create an entry in %localappdata%\Microsoft\WindowsApps\. But the folder is empty on Windows Server (2019 17763, to be specific).

I am not sure whether this issue happens to all Windows Server version. But on 17763, I write a demo to test that and it's 100% reproducible.

Steps to reproduce the bug

1. Create a new WinUI3 C++ project, packaged
2. Add this under the Application node in Package.appxmanifest

        <Extensions>
            <uap3:Extension Category="windows.appExecutionAlias" Executable="_22_ExecutionAliasNotFound_WinUI.exe" EntryPoint="Windows.FullTrustApplication">
                <uap3:AppExecutionAlias>
                    <desktop:ExecutionAlias Alias="winuiBugTest.exe"/>
                </uap3:AppExecutionAlias>
            </uap3:Extension>
        </Extensions>

3. Build a msix package, deploy on Windows Server. Run winuiBugTest.exe, and it will report the file is not found.

Expected behavior

The app should run

Screenshots

NuGet package version

Windows App SDK 1.6.3: 1.6.241114003

Packaging type

Packaged (MSIX)

Windows version

No response

IDE

Visual Studio 2022

Additional context

Using uap5 also does not work. And I don't even know what are the differences

            <uap5:Extension Category="windows.appExecutionAlias" Executable="_22_ExecutionAliasNotFound_WinUI.exe" EntryPoint="Windows.FullTrustApplication">
                <uap5:AppExecutionAlias>
                    <uap5:ExecutionAlias Alias="winuiBugTest.exe"/>
                </uap5:AppExecutionAlias>
            </uap5:Extension>

repro

[DrusTheAxe]

@brialmsft @kanismohammed @sshilov7 is this a code or doc bug? Server 2019 is 17763 aka RS5 (though not Desktop SKU) and the docs for uap3:ExecutionAlias say Minimum OS Version = Windows 10 version 1607 (Build 14393) with no mention of caveat or restriction outside Desktop.

Using uap5 also does not work. And I don't even know what are the differences

Different minimum OS requirements and some functionality. But agreed, the docs are a little confusing and in need of love. I've passed along word to see this addressed.

ExecutionAlias is supported across 6 XML namespaces

Namespace	Minimum OS Required
desktop	Windows 10 version 1607 (Build 14393)
desktop4	Windows 10, Build 17134, Version 1803
desktop10	Windows 11 - Build 22621
uap3	Windows 10 version 1607 (Build 14393)
uap5	Windows 10 version 1709 (Build 16299)
uap8	Windows 10 version 1903 (Build 18362)

You can spot differences comparing the different pages (though even that seems inconsistently incomplete):

• desktop10 adds
  Subsystem, UseDesktopChangeRouter, DropTarget, UseUrl, EnvironmentPath, DropTarget, SupportedProtocols
• desktop4 adds Subsystem
• uap8 adds AllowOverride

The evolutionary summary seems to be...

• desktop supports ExecutionAlias
• uap3 = desktop plus desktop4:Subsystem
• uap5 = uap3 plus uap10:Subsystem
• uap8 = uap5 plus uap8:AllowOverride and several desktop10 attributes (UseDesktopChangeRouter, DropTarget, UseUrl, EnvironmentPath, DropTarget, SupportedProtocols)

desktop4 and desktop10 have no doc page but are mentioned on some of the other pages. I'm unsure if that's a a bug or intentional as they're only attributes and the docs only add pages for elements.

https://learn.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/what-s-changed-in-windows-10 provides a master namespace / OS version cross-reference. Thus we can fill in the Minimum OS Required fields in the table above despite no doc pages specifically for desktop4 or desktop10

[HO-COOH]

ExecutionAlias is supported across 5 XML namespaces

@DrusTheAxe That is 6 my bro, and is way too epic for any developers to handle just for registering an alias. It might well deserve its own doc for that. 😂

[KevinLaMS]

Kevin, menace Anis.

[DrusTheAxe]

ExecutionAlias is supported across 5 XML namespaces

@DrusTheAxe That is 6 my bro, and is way too epic for any developers to handle just for registering an alias. It might well deserve its own doc for that. 😂

Snicker. And doh! Fixed the typo thanks

It's actually not that complicated...in theory

We don't break older systems with newer bits - additive, yes, more relaxed, yes (e.g. required->optional) but not more restrictive. Thus uap5>uap3, uap8>uap5, etc.

The uap# namespaces are a single lineage of versioning supported by OneCore platforms i.e. most Windows SKUs (for example, not nanoserver). The desktop# namespaces are another lineage of versioning supported on 'desktop' SKUs (e.g. Desktop aka Client yes, Xbox not). Thus desktop10>desktop4, etc. General rule of thumb is pick the oldest (lowest) one with your needed features, so you get the your desired functionality on the widest variety of systems, and likewise prefer uap# over desktop# (or xbox# or other platform-specific namespaces) if all else is equal to you.*

In this particular case the feature's evolution, er, meandered :P a little. Coupled with the missing desktop4+10 pages can make it a little hard to follow. Apologies, we'll try to do better in the future.

If all you want is to define an alias it's trivial -- use <uap3:executionAlias>. Simple, and that goes waaay back. Of course if you want some of the newer knobs you need a newer namespace, and don't expect that on older systems. IOW versioning is hard. But that's an age old story

Thanks for the discussion/feedback. Much appreciated, as always.

--DrusTheAxe

* P.S. We've been shifting away from platform# versioning to feature# as it's more flexible across space and time. It's easy to add something to a new e.g. uap19...but then a year later when asked "Hey, can you bring that downlevel?" we can't just change e.g. uap12. We did this a few times with variants e.g. uap12, uap12a, uap12b but it has its complications. In recent years we've been shifting to the more functional naming, e.g. com, com2, com3... as the platform-y uap# was a rather broad net to cast. The functional naming is easier to grok and to evolve so we've been leaning in more on that lately. You'll continue seeing some new platform# evolutions largely because preexisting namespaces. As always, 20-20 hindsight is the clearest sight... :P