MSIX Packaging Tool failure due to protocol handler

%3CLINGO-SUB%20id%3D%22lingo-sub-2036927%22%20slang%3D%22en-US%22%3EMSIX%20Packaging%20Tool%20failure%20due%20to%20protocol%20handler%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2036927%22%20slang%3D%22en-US%22%3E%3CP%3EI%20filed%20a%20feedback%20hub%20issue%20on%20the%20failure%20attaching%20both%20the%20manifest%20file%20and%20log%20from%20the%20attempt.%20This%20post%20provides%20additional%20information%20that%20might%20be%20helpful%20to%20the%20team.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EI%20have%20now%20verified%20that%20I%20correctly%20surmised%20the%20issue%20by%20manipulating%20the%20manifest%20in%20the%20sequence%20editor%20prior%20to%20saving%20the%20package.%26nbsp%3B%20These%20results%20show%20that%20there%20are%20two%20issues%3A%3C%2FP%3E%0A%3COL%3E%0A%3CLI%3EThe%20packaging%20tool%20incorrectly%20believes%20that%20a%20protocol%20handler%20with%20a%20uri%20name%20of%20only%20two%20characters%20requires%20the%20UAP10%20prefix%20rather%20than%20UAP3.%26nbsp%3B%20This%20means%20that%26nbsp%3B%3CEM%3Eif%3C%2FEM%3E%20the%20package%20was%20generated%20it%20would%20not%20work%20on%20Operating%20Systems%20prior%20to%202004%20unnecessarily.%3C%2FLI%3E%0A%3CLI%3EMakeAppx%20rejects%20the%20UAP10%20syntax%20generated%20by%20the%20tool.%26nbsp%3B%20My%20review%20of%20the%20generated%20manifest%20suggests%20that%20the%20syntax%20is%20correct%20according%20to%20the%20schemas%20(but%20perhaps%20I%20missed%20something).%26nbsp%3B%3C%2FLI%3E%0A%3C%2FOL%3E%0A%3CP%3ESpecifically%2C%20I%20found%20that%20I%20could%20edit%20the%20manifest%20inside%20the%20packaging%20tool%2C%20prior%20to%20saving%20the%20package%2C%20and%20the%20package%20saves%20successfully.%20The%20changes%20made%20were%20simply%20to%20change%20the%20uap10%20prefix%20to%20uap3%20on%20the%20elements%20for%20that%20protocol%20handler.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2044573%22%20slang%3D%22en-US%22%3ERe%3A%20MSIX%20Packaging%20Tool%20failure%20due%20to%20protocol%20handler%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2044573%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%3BHa!%20I%20forgot%20that%20I'd%20already%20figured%20that%20out.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EGlad%20to%20hear%20the%20newer%20version%20of%20the%20packaging%20tool%20does%20this%20correctly%20now%2C%20but%20guess%20what%3F%26nbsp%3B%20We%20didn't%20know%20there%20was%20a%20newer%20version.%26nbsp%3B%20Why%3F%20Because%20(as%20far%20as%20I%20know)%20there%20was%20no%20announcement%20of%20it%20in%20the%20community%20portal.%26nbsp%3B%20As%20the%20VM%20used%20for%20the%20packaging%20tool%20is%20constantly%20reverted%20to%20a%20snapshot%20it%20never%20gets%20updated%20from%20the%20store%20-%20we%20have%20to%20have%20notice%20somehow.%3C%2FP%3E%3C%2FLINGO-BODY%3E
MVP

I filed a feedback hub issue on the failure attaching both the manifest file and log from the attempt. This post provides additional information that might be helpful to the team.

 

I have now verified that I correctly surmised the issue by manipulating the manifest in the sequence editor prior to saving the package.  These results show that there are two issues:

  1. The packaging tool incorrectly believes that a protocol handler with a uri name of only two characters requires the UAP10 prefix rather than UAP3.  This means that if the package was generated it would not work on Operating Systems prior to 2004 unnecessarily.
  2. MakeAppx rejects the UAP10 syntax generated by the tool.  My review of the generated manifest suggests that the syntax is correct according to the schemas (but perhaps I missed something). 

Specifically, I found that I could edit the manifest inside the packaging tool, prior to saving the package, and the package saves successfully. The changes made were simply to change the uap10 prefix to uap3 on the elements for that protocol handler.

2 Replies

@TIMOTHY MANGAN 

 

I believe this is related to what was described in WinSCP fails both manually and automated on W10 20H2 with latest tool build - Microsoft Tech Communi...

 

As you said the tool used the uap10 prefix instead of uap3 unnecesarily. Then, it created an <uap10:Protocol> element that contained a <uap:DisplayName> instead of <uap10:DisplayName> causing MakeAppx to reject it.

 

Both issues should be fixed in the latest Insider build of the tool (1.2020.1219.0). I.e., it should use uap3:Protocol in this case and uap10 only when actually needed (e.g. length >= 40), and when it does, the element has the appropriate children.

@Chacon Ha! I forgot that I'd already figured that out.

 

Glad to hear the newer version of the packaging tool does this correctly now, but guess what?  We didn't know there was a newer version.  Why? Because (as far as I know) there was no announcement of it in the community portal.  As the VM used for the packaging tool is constantly reverted to a snapshot it never gets updated from the store - we have to have notice somehow.