Forum Discussion
Solved
The ms-appinstaller protocol has been disabled.
I just found out that users can no longer install my MSIX from my website. This is a WPF application packaged with "Windows Application Packaging Project" (wapproj). When users click the "Get the app...
bvenhaus Thank you for your question. We removed the ms-appinstaller custom scheme due to a security vulnerability. We do intend to bring this back, and are working on it. For now, you can update the link on your website by removing 'ms-appinstaller:?source='
<html> <body> <h1> MyApp Web Page </h1> <a href="http://mywebservice.azureedge.net/HubApp.msix"> Install app package </a> <a href="http://mywebservice.azureedge.net/HubAppBundle.msixbundle"> Install app bundle </a> <a href="http://mywebservice.azureedge.net/HubAppSet.appinstaller"> Install related set </a> </body> </html>
@jimddour Ok thanks.
I was able to get this working without loss of functionality by:
- updating my mime types of the server hosting the app installer (AppInstallerUri flag on vsbuild) to set the .appinstaller extension to 'application/octet-stream'
- distribute to my users the produced .appinstaller file (https://{AppInstallerUri}/{AppName}.appinstaller) [You can check this under Additional links -> App Installer File].
From what I see, updates are still working and the only change is the above URL downloads the .appinstaller file to run opposed to the 'get the app' link which streams it to the browser.
I've just put a link to the https://{AppInstallerUri}/{AppName}.appinstaller on my products landing page. (this URL stays the same and is updated automatically for new deployments through an Azure DevOps pipeline)
I was able to get this working without loss of functionality by:
- updating my mime types of the server hosting the app installer (AppInstallerUri flag on vsbuild) to set the .appinstaller extension to 'application/octet-stream'
- distribute to my users the produced .appinstaller file (https://{AppInstallerUri}/{AppName}.appinstaller) [You can check this under Additional links -> App Installer File].
From what I see, updates are still working and the only change is the above URL downloads the .appinstaller file to run opposed to the 'get the app' link which streams it to the browser.
I've just put a link to the https://{AppInstallerUri}/{AppName}.appinstaller on my products landing page. (this URL stays the same and is updated automatically for new deployments through an Azure DevOps pipeline)
I should have read closer, this is good you have found a way to "automate" the work-around, but it does not fix the fact that users must save a file they downloaded from the internet and execute it themselves. Once on their hard drives this can be distributed in many ways intended or otherwise. The real advantage here is that updates can be supported in the same multi-step way, or are the users not required to save the next update to the hard drive and execute it because it just happens in the background?
Yes it may not satifsy your use case. I am ok with my users downloading a file instead as a work-around for now until Microsoft can restore the original functionality securely.
You can set the https://docs.microsoft.com/en-us/uwp/schemas/appinstallerschema/element-update-settings update-settings flag to OnLaunch or AutomaticBackgroundTask and the https://docs.microsoft.com/en-us/uwp/schemas/appinstallerschema/element-automatic-background-task element-automatic-background-task flag to check for updates periodically once installed.- Just as an fyi, we are not seeing automatic updates work via our workaround.
