Forum Discussion
Custom URL handler with MSIX package
https://learn.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-desktop10-supportedprotocols
- josuegomesAug 09, 2024Copper Contributor
TIMOTHY_MANGANthank you for the reply. I'm actually looking to register an URL association. See https://learn.microsoft.com/en-us/windows/win32/shell/default-programs#registering-an-application-for-use-with-default-programs
I want to associate my application for a custom URL.
- Aug 10, 2024
[Disclaimer: I don't do much with URLs, but maybe this will help]
I think that you can have an Application element (Application (Windows 10) - Windows UWP applications | Microsoft Learn) in the AppXManifest and use the StartPage parameter without the EntryPoint parameter. The value of StartPage would be the URL. If you don't want a start menu item, you would add the AppListEntry="none" parameter/value to the Uap:VisualItems child element. You would then add the UAP (or UAP3) FileTypeAssociation element to define the file type(s) that should trigger it. [See note below about the default issue]
So I've never done the above, so if that doesn't work, then what I have successfully done is to add components from the Package Support Framework. Add a copy of PsfLauncher.exe, and PsfRuntime.dll, and PsfRunDll.exe, to the package ingredients. Add the Application element in the AppXManifest with an EntryPoint to PsfLauncher. Also add a config.json file with a Process entry for the AppID on your Application element that lists your URL as the "executable". Add the FileTypeAssociation to the Application element (and the AppListEntry if you don't want the start menu item). The file type association triggers PsfLauncher to run which will process the config.json file and seeing the URL will switch to performing a shell launch of the URL, for which the shell will ask the user's default browser to start and go to the URL page. [See note below about the default issue]
Default Issue: With File Type Associations in the AppXManifest, the system doesn't like FTA conflict. So if the file type isn't already present on the system, your application becomes the default. But unlike the registry style registration, a vendors app can no longer say make me the default even if there is something already there. They leave it to the end-user to later select which app they want as the default. Since your old registration used the RegisteredApplications approach, you should already be familiar with how user's control this (as it is the same), but if you expected it to be the default because your .xyz registration previously asked to become the default you might be surprised at this. I believe this to be intentional by Microsoft and is very unlikely to change.