Adding URI activation to AppxManifest.xml

%3CLINGO-SUB%20id%3D%22lingo-sub-1639966%22%20slang%3D%22en-US%22%3EAdding%20URI%20activation%20to%20AppxManifest.xml%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1639966%22%20slang%3D%22en-US%22%3E%3CP%3EHello%2C%3CBR%20%2F%3E%3CBR%20%2F%3EWe%20have%20automated%20the%20EXE%20to%20MSIX%20packaging%20process.%20However%2C%20we%20need%20the%20created%20MSIX%20package's%26nbsp%3BAppxManifest.xml%20to%20contain%20a%20URI%20scheme%20for%20URI%20activation(%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fuwp%2Flaunch-resume%2Fhandle-uri-activation)%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fuwp%2Flaunch-resume%2Fhandle-uri-activation)%3C%2FA%3E.%20This%20is%20currently%20possible%20through%20the%20MsixPackagingTool.exe%20GUI%20version(package%20editor).%3CBR%20%2F%3E%3CBR%20%2F%3E1)%20Is%20it%20possible%20to%20specify%20this%20URI%20through%20the%20MSIX%20template%3F%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FP%3E%3CP%3E2)%20If%20not%2C%26nbsp%3Bis%20there%20a%20way%20to%20automate%20the%20addition%20of%20these%20entries%20using%20any%20command%20line%20tools%20after%20creating%20the%20MSIX%20package%3F%3CBR%20%2F%3E%3CBR%20%2F%3EThank%20you!%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-1639966%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EAppxManifest.xml%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3Epackage%20editor%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EURI%20activation%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1646058%22%20slang%3D%22en-US%22%3ERe%3A%20Adding%20URI%20activation%20to%20AppxManifest.xml%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1646058%22%20slang%3D%22en-US%22%3E%3CP%3EHi%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F783974%22%20target%3D%22_blank%22%3E%40uvinabeysinghe%3C%2FA%3E%2C%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3ETo%20clarify%20your%20issue%2C%20is%20the%20URI%20handler%20you%20want%20added%20to%20the%20msix%20package%20a%20URI%20handler%20that%20the%20exe%20already%20registers%3F%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EMSIX%20packaging%20tool%20already%20scans%20the%20registry%20for%20protocol%20registrations%20during%20conversion.%20If%20we%20are%20missing%20an%20expected%20registration%2C%20I'd%20like%20to%20identify%20what%20we%20missed%20during%20conversion.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EIf%20you%20need%20to%20add%20this%20protocol%20handler%20after%20conversion%3A%3C%2FP%3E%0A%3CP%3ERE%201%3A%20No%2C%20the%20Command%20line%20interface%20template%20does%20not%20support%20specifying%20a%20protocol%20for%20addition.%3C%2FP%3E%0A%3CP%3ERE%202%3A%20You%20could%20write%20a%20script%20that%20uses%20makeappx%20(%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2Fappxpkg%2Fmake-appx-package--makeappx-exe-%23to-extract-files-from-a-package%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%22%3EApp%20packager%20(MakeAppx.exe)%20-%20Win32%20apps%20%7C%20Microsoft%20Docs%3C%2FA%3E)%20to%20unpack%20the%20msix%2C%20use%20your%20favorite%20text%20manipulator%20to%20edit%20the%20manifest%20file%2C%20then%20repack%20and%20resign%20the%20msix%20with%20makeappx%2Fsigntool.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EIf%20you%20could%20describe%20in%20more%20detail%20the%20specific%20business%20need%2Fscenario%20you%20are%20trying%20to%20address%2C%20that%20would%20help%20us%20prioritize%20and%20evaluate%20whether%20this%20would%20benefit%20from%20specific%20feature%20additions%20to%20the%20tooling.%20Are%20there%20other%20fields%20you%20find%20necessary%20to%20manually%20add%20in%20general%20post%20conversion%3F%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EThanks!%3CBR%20%2F%3EJames%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1647514%22%20slang%3D%22en-US%22%3ERe%3A%20Adding%20URI%20activation%20to%20AppxManifest.xml%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1647514%22%20slang%3D%22en-US%22%3E%3CP%3EHi%20%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F235896%22%20target%3D%22_blank%22%3E%40James%20Pike%3C%2FA%3E%26nbsp%3B%2C%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FP%3E%3CDIV%3E%3CSPAN%3EWe%20have%20created%26nbsp%3B%E2%80%9Cmyapp_setup.exe%E2%80%9D%26nbsp%3Bwhich%20we%20converted%20to%26nbsp%3B%E2%80%9Cmyapp.msix%E2%80%9D.%26nbsp%3B%26nbsp%3BWhen%20we%20install%20%E2%80%9Cmyapp_setup.exe%E2%80%9D%2C%20we%20create%20below%20registry%20keys%20for%20supporting%20the%20uri%20protocol%20%E2%80%9C%3C%2FSPAN%3E%3CSPAN%3E%3CSPAN%3Emyapp-name%3A%2F%2F%E2%80%9C%3C%2FSPAN%3E%3C%2FSPAN%3E%26nbsp%3B%3CBR%20%2F%3E%3C%2FDIV%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CPRE%20class%3D%22lia-code-sample%20language-applescript%22%3E%3CCODE%3EWindows%20Registry%20Editor%20Version%205.00%0A%5BHKEY_LOCAL_MACHINE%5CSOFTWARE%5CClasses%5Cmyapp-name%5D%0A%40%3D%22URL%3Amyapp-name%22%0A%22URL%20Protocol%22%3D%22%22%0A%5BHKEY_LOCAL_MACHINE%5CSOFTWARE%5CClasses%5Cmyapp-name%5Cshell%5D%0A%40%3D%22open%22%0A%5BHKEY_LOCAL_MACHINE%5CSOFTWARE%5CClasses%5Cmyapp-name%5Cshell%5Copen%5D%0A%40%3D%22%22%0A%5BHKEY_LOCAL_MACHINE%5CSOFTWARE%5CClasses%5Cmyapp-name%5Cshell%5Copen%5Ccommand%5D%0A%40%3D%22%5C%22C%3A%5C%5CUsers%5C%5Cusername%5C%5CApplications%5C%5CMyApp%5C%5CMyAppName.exe%5C%22%22%3C%2FCODE%3E%3C%2FPRE%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CDIV%3E%3CP%3E%3CSPAN%3EBut%3C%2FSPAN%3E%3CSPAN%3E%20when%20we%20install%26nbsp%3B%E2%80%9Cmyapp.msix%E2%80%9D%20only%20some%20of%20the%20above%20registry%20keys%20get%20created.%26nbsp%3B%3C%2FSPAN%3E%3CSPAN%3EAlso%2C%20note%20that%20the%20absolute%20path%20to%20the%20exe%20file%20will%20be%20different%20in%20the%20case%20of%20MSIX%20installation%20as%20it%20gets%20installed%20to%20%3C%2FSPAN%3E%3CSPAN%3EC%3A%5C%5CProgram%20Files%5C%5CWindowsApps%20folder.%26nbsp%3B%3C%2FSPAN%3E%3C%2FP%3E%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%3CP%3E%3CSPAN%3EFor%20testing%20purpose%2C%20we%20tried%20to%20manually%20create%20these%20registry%20keys%20after%20installing%20the%20MSIX%20package.%20But%2C%20the%20URI%26nbsp%3Bprotocol%20does%20not%20work%20and%20we%20see%20permission%20denied%20errors%20in%20the%20process%20monitor%20logs.%26nbsp%3B%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%3EWhat%20is%20the%20recommended%20method%20for%20supporting%20URI%20protocols%20in%20MSIX%20packages%3F%20Should%20we%20work%20on%20getting%20the%20registry%20keys%20to%20work%20%2C%20which%20we%20believe%20requires%20fixes%20in%20the%20MSIX%20packaging%20tool.%20%3C%2FSPAN%3E%3C%2FP%3E%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%3CP%3E%3CSPAN%3EOr%2C%20should%20we%20be%20focusing%26nbsp%3Bon%20automating%20the%20addition%20of%20the%20URI%20protocol%20XML%20entries%20in%20the%20App%20Manifest.%20For%20this%20case%2C%20it%20will%20be%20helpful%20if%20you%20could%20create%20an%20enhancement%20request%20for%20supporting%20this%20in%20the%20MSIX%20packaging%20tool.%20If%20this%20is%20what%20is%20recommended%2C%20we%20can%20consider%20using%20the%20MakeAppx%20tool%20for%20now.%26nbsp%3B%3C%2FSPAN%3E%3C%2FP%3E%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%3CP%3E%3CSPAN%3EWe%20would%20like%20to%20automate%20this%20soon.%20Currently%20our%20team%20is%20manually%20creating%20MSIX%20files.%20This%20takes%20a%20lot%20of%20time%20because%20we%26nbsp%3Bhave%20to%26nbsp%3Bcreate%20several%20MSIX%20files%20for%20our%20product%20releases.%26nbsp%3B%3CBR%20%2F%3E%3CBR%20%2F%3EThank%20you!%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FSPAN%3E%3C%2FP%3E%3C%2FDIV%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1650058%22%20slang%3D%22en-US%22%3ERe%3A%20Adding%20URI%20activation%20to%20AppxManifest.xml%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1650058%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F783974%22%20target%3D%22_blank%22%3E%40uvinabeysinghe%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EI%20believe%20the%20supported%20way%20to%20use%20URI%20handlers%20in%20MSIX%20packages%20is%20to%20register%20them%20in%20the%20AppxManifest.xml.%20As%20you%20saw%2C%20creating%20registry%20keys%20pointing%20to%20the%20executable%20inside%20the%20installed%20MSIX%20will%20fail%20due%20to%20lack%20of%20permissions%20to%20access%20the%20WindowsApps%20folder.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EAs%20James%20said%2C%20the%20MSIX%20packaging%20tool%20already%20scans%20the%20registry%20for%20URI%20protocol%20registrations%2C%20and%20from%20the%20snippet%20you%20provided%20the%20tool%20should%20be%20able%20to%20handle%20yours%20during%20conversion.%20For%20this%20you%20would%20not%20add%20something%20to%20the%20template%20but%20change%20the%20installer%20you%20provide%20to%20the%20packaging%20tool.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EYou%20can%20create%20an%20installer%20script%20(e.g.%20a%20Powershell%20script)%20that%20runs%20myapp_setup.exe%20and%20then%20adds%20the%20registry%20keys%20you%20need.%20Then%20give%20this%20installer%20to%20the%20tool.%20The%20tool%20will%20see%20both%20the%20changes%20created%20by%20myapp_setup.exe%20and%20the%20registry%20keys%2C%20and%20it%20will%20create%20the%20appropriate%20manifest%20entries%20for%20you.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EYou%20can%20also%20test%20this%20manually%20without%20a%20script%2C%20but%20you%20will%20want%20to%20create%20the%20script%20to%20automate%20it.%20For%20this%20you%20can%20do%20the%20conversion%20from%20the%20tool%20GUI%2C%20and%20add%20the%20registry%20keys%20while%20in%20the%20Installation%20page%20of%20the%20wizard.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3ELet%20me%20know%20if%20that%20helps.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1662782%22%20slang%3D%22en-US%22%3ERe%3A%20Adding%20URI%20activation%20to%20AppxManifest.xml%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1662782%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F569046%22%20target%3D%22_blank%22%3E%40Luis_Chacon%3C%2FA%3E%26nbsp%3B%20As%20suggested%20above%2C%20we%20can%20consider%20creating%20a%20powershell%20script%20for%20creating%20the%20registry%20keys%2C%20but%20we%20assume%20the%20functionality%20would%20still%20not%20work%20in%20the%20MSIX%20package%20due%20to%20the%20lack%20of%20permissions.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EBased%20on%20this%2C%20we%20think%20that%20automating%20the%20addition%20of%20app%20manifest%20entries%20is%20the%20best%20way%20forward.%20We'll%20try%20to%20use%20the%26nbsp%3B%3CSPAN%3Emakeappx%20tool%20(%3C%2FSPAN%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2Fappxpkg%2Fmake-appx-package--makeappx-exe-%23to-extract-files-from-a-package%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%22%3EApp%20packager%20(MakeAppx.exe)%20-%20Win32%20apps%20%7C%20Microsoft%20Docs%3C%2FA%3E)%20to%20achieve%20this.%20It%20will%20be%20helpful%20if%20the%20MSIX%20converter%20is%20enhanced%20in%20the%20future%20to%20support%20this%20workflow.%3CBR%20%2F%3E%3CBR%20%2F%3EThank%20you!%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1665608%22%20slang%3D%22en-US%22%3ERe%3A%20Adding%20URI%20activation%20to%20AppxManifest.xml%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1665608%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F783974%22%20target%3D%22_blank%22%3E%40uvinabeysinghe%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EYou%20are%20right%20in%20that%20using%20the%20registry%20keys%20to%20register%20the%20URL%20handler%20pointing%20to%20the%20installed%20MSIX%20package%20will%20not%20work.%20What%20I%20am%20suggesting%20instead%20is%20to%20create%20the%20registry%20keys%20so%20that%20the%20MSIX%20Packaging%20Tool%20generates%20the%20manifest%20entries%20you%20need.%20I%20didn't%20mean%20it%20as%20an%20alternative%20to%20adding%20the%20manifest%20entries%2C%20but%20as%20a%20way%20to%20let%20the%20tool%20do%20add%20them%20for%20you.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EThis%20only%20works%20during%20conversion%20and%20not%20after%20creating%20the%20package.%20If%20the%20packaging%20tool%20sees%20that%20the%20installer%20creates%20a%20registration%20for%20%22C%3A%5CUsers%5Cusername%5CApplications%5CMyApp%5CMyAppName.exe%22%20to%20handle%20protocol%20%22myapp-name%22%2C%20then%20it%20will%20create%20the%20manifest%20entries%20needed%20to%20do%20the%20same%20in%20the%20package.%3C%2FP%3E%3C%2FLINGO-BODY%3E
Occasional Contributor

Hello,

We have automated the EXE to MSIX packaging process. However, we need the created MSIX package's AppxManifest.xml to contain a URI scheme for URI activation(https://docs.microsoft.com/en-us/windows/uwp/launch-resume/handle-uri-activation). This is currently possible through the MsixPackagingTool.exe GUI version(package editor).

1) Is it possible to specify this URI through the MSIX template?

2) If not, is there a way to automate the addition of these entries using any command line tools after creating the MSIX package?

Thank you!

7 Replies

Hi @uvinabeysinghe,

 

To clarify your issue, is the URI handler you want added to the msix package a URI handler that the exe already registers?

 

MSIX packaging tool already scans the registry for protocol registrations during conversion. If we are missing an expected registration, I'd like to identify what we missed during conversion.

 

If you need to add this protocol handler after conversion:

RE 1: No, the Command line interface template does not support specifying a protocol for addition.

RE 2: You could write a script that uses makeappx (App packager (MakeAppx.exe) - Win32 apps | Microsoft Docs) to unpack the msix, use your favorite text manipulator to edit the manifest file, then repack and resign the msix with makeappx/signtool.

 

If you could describe in more detail the specific business need/scenario you are trying to address, that would help us prioritize and evaluate whether this would benefit from specific feature additions to the tooling. Are there other fields you find necessary to manually add in general post conversion?

 

Thanks!
James

Hi @James Pike ,

We have created “myapp_setup.exe” which we converted to “myapp.msix”.  When we install “myapp_setup.exe”, we create below registry keys for supporting the uri protocol “myapp-name://“ 

 

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\myapp-name]
@="URL:myapp-name"
"URL Protocol"=""
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\myapp-name\shell]
@="open"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\myapp-name\shell\open]
@=""
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\myapp-name\shell\open\command]
@="\"C:\\Users\\username\\Applications\\MyApp\\MyAppName.exe\""

 

 

But when we install “myapp.msix” only some of the above registry keys get created. Also, note that the absolute path to the exe file will be different in the case of MSIX installation as it gets installed to C:\\Program Files\\WindowsApps folder. 

 

For testing purpose, we tried to manually create these registry keys after installing the MSIX package. But, the URI protocol does not work and we see permission denied errors in the process monitor logs. 

 

What is the recommended method for supporting URI protocols in MSIX packages? Should we work on getting the registry keys to work , which we believe requires fixes in the MSIX packaging tool.

 

Or, should we be focusing on automating the addition of the URI protocol XML entries in the App Manifest. For this case, it will be helpful if you could create an enhancement request for supporting this in the MSIX packaging tool. If this is what is recommended, we can consider using the MakeAppx tool for now. 

 

We would like to automate this soon. Currently our team is manually creating MSIX files. This takes a lot of time because we have to create several MSIX files for our product releases. 

Thank you!

@uvinabeysinghe 

 

I believe the supported way to use URI handlers in MSIX packages is to register them in the AppxManifest.xml. As you saw, creating registry keys pointing to the executable inside the installed MSIX will fail due to lack of permissions to access the WindowsApps folder.

 

As James said, the MSIX packaging tool already scans the registry for URI protocol registrations, and from the snippet you provided the tool should be able to handle yours during conversion. For this you would not add something to the template but change the installer you provide to the packaging tool.

 

You can create an installer script (e.g. a Powershell script) that runs myapp_setup.exe and then adds the registry keys you need. Then give this installer to the tool. The tool will see both the changes created by myapp_setup.exe and the registry keys, and it will create the appropriate manifest entries for you.

 

You can also test this manually without a script, but you will want to create the script to automate it. For this you can do the conversion from the tool GUI, and add the registry keys while in the Installation page of the wizard.

 

Let me know if that helps.

@Chacon  As suggested above, we can consider creating a powershell script for creating the registry keys, but we assume the functionality would still not work in the MSIX package due to the lack of permissions.

 

Based on this, we think that automating the addition of app manifest entries is the best way forward. We'll try to use the makeappx tool (App packager (MakeAppx.exe) - Win32 apps | Microsoft Docs) to achieve this. It will be helpful if the MSIX converter is enhanced in the future to support this workflow.

Thank you!

@uvinabeysinghe 

You are right in that using the registry keys to register the URL handler pointing to the installed MSIX package will not work. What I am suggesting instead is to create the registry keys so that the MSIX Packaging Tool generates the manifest entries you need. I didn't mean it as an alternative to adding the manifest entries, but as a way to let the tool do add them for you.

 

This only works during conversion and not after creating the package. If the packaging tool sees that the installer creates a registration for "C:\Users\username\Applications\MyApp\MyAppName.exe" to handle protocol "myapp-name", then it will create the manifest entries needed to do the same in the package.

Hi @Chacon ,

 

We tried running the powershell script to install the registry keys during the conversion and the url protocol entries get added to the app manifest correctly.

 

We are trying to understand why the MSIX package converter detects the registry keys created from the powershell script and does not detect the same registry keys created by our app installers during installation.

 

We also recently noticed that the MSIX package converter adds the url protocol app manifest key for one of our app “setup.exe"s but not the rest of "setup.exe"s without the powershell script adding the registry keys. We are wondering why it works for some app installers and not for the others.

Thanks!

@uvinabeysinghe 

 

Glad to hear it worked.

 

To investigate why it detects the URL handler for only some apps, you can check if the registry keys were captured by the packaging tool by manually inspecting the virtual registry of the package using the Package Editor. Whether the keys are in the virtual registry or not, has no effect on the URL handler being registered but it tells you for certain whether the problem is that the packaging tool is not seeing the registry keys being created, or that it does see them but does not handle them correctly.

 

If the tool is not seeing the keys being created, it could be for example that they are being created after the tool stops monitoring system changes.

 

If the MSIX packaging tool is not interpreting the registry keys correctly to create the manifest entry, you can inspect the conversion logs which may tell you why the URL protocol handler was not added. You can also share the conversion logs here or through Feedback Hub for us to take a look. If you do, please review your logs for any private information you would prefer not to share with us.