-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error hosting MSIX packages with the AppInstaller technology #26
Comments
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. |
@miwebst That'd be cool, but I think the more pressing matters are that:
|
@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! |
@miwebst Yep, the quotes. Sounds like you're on top of it, thanks! |
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! |
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. |
@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. |
Can confirm ETags are now quoted properly, HEAD Content-Length is non-zero, and ranged requests are working. @qmatteoq Your appinstaller works now. |
Hello @miwebst, unfortunately the problem seems to be still there, even if indeed something changed. 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). |
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 |
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! |
When I said it was working 10 days ago, I verified ranged support was already present. So what changed? |
We added range request support :) it was missing before. Closing this issue. |
Ah @qmatteoq clarified my previous test may have been tainted and produced a false positive https://twitter.com/qmatteoq/status/1266282344463228928. Case closed then. |
I have the same issue but i dont know how to add range request support |
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? |
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? |
Hey, I'm having an almost similar problem with appinstaller file. I have created a blob container named $web, which should work as a static app container. During the build, using AzureBlob File Copy task several files are placed into the above container:
Html is the most basic one having in the body only a link: Then I click on the link - I don't get the window that allows saving the appinstaller file, but instead, the page with the xml content of this file is shown. After some digging, it turns out that if, using Azure Storage Explorer, right-click on the Myapp.appinstaller and change the ContentType from "text/xml" to "application/appinstaller" - everything starts to work as expected. I can't do the mouse trick after the build every time. I added web.config file with the following content:
Didn't help. I added staticwebapp.config.json
Also didn't help. Only manual change inside Azure Storage Explorer working. What should I do to make the link click open the appinstaller for download, not showing its content? |
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:
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:
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
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
The text was updated successfully, but these errors were encountered: