Static-web-apps: Error hosting MSIX packages with the AppInstaller technology

[qmatteoq]

I'm currently using the Static Website feature of Azure Storage to host and distribute my desktop applications packaged as MSIX. They are distributed using the AppInstaller technology. This means that, on my website, I have to deploy:

• A static web page
• An .appinstaller file, which is a XML file that describes where the MSIX package is available and defines the auto-update logic
• A MSIX file, which is the package that contains the desktop application

Here is an example of a website which I'm using to host such a package: https://contosoexpensesgithub.z28.web.core.windows.net/

After seeing the announcement at Build of Static Web Apps, I decided to give it a try and to setup a GitHub Action to build, package and deploy my desktop apps on a Static Web App.
The workflow works fine, but the installation operation always fails. When I click on the Get the app button (which invokes the .appinstaller file using the ms-appinstaller protocol included in Windows 10), I get the following error:

My suspect is that this is happening because Static Web Apps doesn't support the required MIME types. The official documentation on MSIX deployment on Azure Web App, in fact, says that you must add the following MIME types:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <!--This is to allow the web server to serve resources with the appropriate file extension-->
    <staticContent>
      <mimeMap fileExtension=".appx" mimeType="application/appx" />
      <mimeMap fileExtension=".msix" mimeType="application/msix" />
      <mimeMap fileExtension=".appxbundle" mimeType="application/appxbundle" />
      <mimeMap fileExtension=".msixbundle" mimeType="application/msixbundle" />
      <mimeMap fileExtension=".appinstaller" mimeType="application/appinstaller" />
    </staticContent>
  </system.webServer>
</configuration>

I tried to include a web.config in the root of the project, but nothing has changed.

I took the same exact GitHub action and I changed the deployment to Azure Storage and everything works, so I tend to exclude a problem in the CI/CD workflow or in the AppInstaller file.

Steps to reproduce the problem

1. Open the website https://gentle-sea-007a8f903.azurestaticapps.net/, which is hosted on Azure Static Web App
2. Click on Install for x86
3. Observe how the installation fails with the error: The .appinstaller file is invalid
4. Open the website https://contosoexpensesgithub.z28.web.core.windows.net/, which is hosted on Azure Storage
5. Click on Install for x86
6. Observe how, in this case, the installation completes fine.

Any idea what might happen here?

Update: I'm adding a link to a Twitter thread where Rafel Rivera shares some interesting insights about his troubleshooting https://twitter.com/qmatteoq/status/1264283848004841472?s=19

[miwebst]

Yes these mimetypes are missing on our side, we are working on adding the ability for customers to define mime type overrides. We can look at adding these as well.

[riverar]

@miwebst That'd be cool, but I think the more pressing matters are that:

• az staticweb sends bad ETags
• az staticweb sends zero content-length on HEAD requests
• az staticweb doesn't appear to support HTTP ranged requests

[miwebst]

@riverar, for the bad ETags, are you referring to the missing ""? We have a bug for this and it is rolling out with our next release.

For HEAD requests, we similarly have a bug out for this. That is being worked on.

We are missing support for ranged requests right now. I'll add this to our backlog!

[riverar]

@miwebst Yep, the quotes. Sounds like you're on top of it, thanks!

[qmatteoq]

Thanks @miwebst ! Is it possible for you to update this issue when the first two bugs have been addressed? I would like to give a try if this would be enough or if we can't support this scenario until we get also ranged requests support.

Thanks!

[miwebst]

Yes, I will update this thread. ETag fix will come early this week. HEAD requests with content length will come later on as it is still being worked on.

[miwebst]

@qmatteoq so ETags should be working now and if you push an update to your site then you should also see that the HEAD requests now contain the content length.

[riverar]

Can confirm ETags are now quoted properly, HEAD Content-Length is non-zero, and ranged requests are working.

@qmatteoq Your appinstaller works now.

[qmatteoq]

Hello @miwebst, unfortunately the problem seems to be still there, even if indeed something changed.
Now I'm getting a different kind of error:

However, the .appinstaller file is there, since I can download it if I use the direct URL. In the network trace below you can see the first request is failing, which is the one using the ms-appinstaller protocol (ms-appinstaller:?source=https://gentle-sea-007a8f903.azurestaticapps.net/ContosoExpenses.Package_x86.appinstaller), while the second one with the direct link is successful (https://gentle-sea-007a8f903.azurestaticapps.net/ContosoExpenses.Package_x86.appinstaller).

[miwebst]

This should be fixed as we added range request support, I tried out the site and the installer was able to recognize the application. Let me know if you run into any more issues

[qmatteoq]

Awesome, thanks @miwebst ! I confirm that range request support was the missing feature for my scenario. Now everything is working as expected. Feel free to close the issue. Thanks!

[riverar]

When I said it was working 10 days ago, I verified ranged support was already present. So what changed?

[miwebst]

We added range request support :) it was missing before. Closing this issue.

[riverar]

~@miwebst I hand verified/confirmed this, so something isn't right here. Was this perhaps deployed May 28 and took a while to trickle out and I just got lucky hitting an updated node?~

Ah @qmatteoq clarified my previous test may have been tainted and produced a false positive https://twitter.com/qmatteoq/status/1266282344463228928. Case closed then.

[georgait]

I have the same issue but i dont know how to add range request support

[qmatteoq]

Hello @georgait you shouldn't need to do anything. Range request support was something that needed to be added from the Azure Static Website team and they did it, so you should be good to go. Are you getting the same exact problem?

[georgait]

Hello @qmatteoq i have the same issue but i dont use Azure, i use Windows server 2019 Datacenter. Do you have any idea how to solve this problem?