Custom URL handler with MSIX package

Question

I have packaged my classic Win32 application as an MSIX package to be distributed on the Microsoft Store.

Now, I want to register it as a handler for a custom URL protocol. With the classic Win32 installation, it was just a matter of creating some registry entries. However, I couldn’t find a way to do that with the AppxManifest.xml file.

Ideas?

timothy_mangan · Answer

Assuming that you want to register a traditional "protocol handler" that used to register under Classes\Protocols, the equivalent is in the desktop10 extension. As noted in the documentation, this is a package level extension in the AppXManifest.

https://learn.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-desktop10-supportedprotocols

timothy_mangan · Answer

Oh, the desktop10 schema I think might be Windows 11 only.  So the older version that works on 10 and 11 is here:  https://learn.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-uap-protocol

josuegomes · Answer

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.

timothy_mangan · Answer

josuegomes&nbsp;
&nbsp;
[Disclaimer: I don't do much with URLs, but maybe this will help]
&nbsp;
I think that you can have an Application element (Application (Windows&nbsp;10) - Windows UWP applications | Microsoft Learn) in the AppXManifest and use the StartPage parameter without the EntryPoint parameter.&nbsp; The value of StartPage would be the URL.&nbsp; If you don't want a start menu item, you would add the AppListEntry="none" parameter/value to the Uap:VisualItems child element.&nbsp; 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]
&nbsp;
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.&nbsp; Add a copy of PsfLauncher.exe, and PsfRuntime.dll, and PsfRunDll.exe, to the package ingredients.&nbsp; Add the Application element in the AppXManifest with an EntryPoint to PsfLauncher.&nbsp; Also add a config.json file with a Process entry for the AppID on your Application element that lists your URL as the "executable".&nbsp; 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.&nbsp; [See note below about the default issue]
&nbsp;
Default Issue:&nbsp; With File Type Associations in the AppXManifest, the system doesn't like FTA conflict.&nbsp; So if the file type isn't already present on the system, your application becomes the default.&nbsp; But unlike the registry style registration, a vendors app can no longer say make me the default even if there is something already there.&nbsp; They leave it to the end-user to later select which app they want as the default.&nbsp; 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.&nbsp; I believe this to be intentional by Microsoft and is very unlikely to change.

Forum Discussion

Custom URL handler with MSIX package

Share

Resources