WinSCP fails both manually and automated on W10 20H2 with latest tool build

[xenappblog]

I think its related to a registry key creating that Tim M talked about earlier.

[#2]

@xenappblog 

Trond, I'm not sure which registry thing you refer to, but  WinSCP did need the registry fix for HKCU added to the 2004 runtime for end-user configuration issues.  I have not yet tested that app against 20H2, but the error that looks different.

Possibly this is the return of a capturing issue the MSIX Packaging Tool used to have in the early days.

That mentioned .rnd file is in the ingredients list when the makeappx command is run, but is unavailable.  I used to see that behavior when a file got created and removed.  Sometimes this was because of an unrelated background process, although in this case it seems to be part of the app. 

As you are building against a new version of the OS, using a new packaging tool, packaging remotely, and with an automated script, I'd suggest suggest isolating out some of that.

[#3]

Hi @xenappblog 

I tried converting WinSCP and I believe the error you are seeing is due to an invalid protocol association. The MSIX Packaging Tool creates this protocol association:

<uap10:Protocol Name="s3" Parameters="/Unsafe &quot;%1&quot;">
  <uap:DisplayName>s3</uap:DisplayName>
  <uap:Logo>Assets\dav.png</uap:Logo>
</uap10:Protocol>

 It should be using uap3:Protocol, not uap10:Protocol. There are other protocol associations, but only this one seems to be invalid.

To fix this you can edit the manifest file manually using the Package Editor. To do this, in the "Create new package" page of the tool, click "Package editor" instead of "Create" and then look for the "Open file" button at the bottom of the page.

[#4]

Thanks Luis that worked. Here's the script if anyone wants to play
https://github.com/haavarstein/Applications/tree/master/Misc/WinSCP

[#5]

@Chacon @xenappblog 

While working for this example, the explanation needs work.  Protocol handles may be defined using either uap, uap3, or uap10 syntax.  Unlike other parts of the schemas though, you can't mix and match the versions used for sub-elements. 

Uap3 added the "Parameters" attribute which would be needed for this application, but uap10 extended the character sets used the "Name" parameter which could be needed by some apps.  Since using uap10 implies an 1904 OS dependency at the client, it is better to chose to stick with uap3 for this example, but for others sticking with uap10 might be needed..