SOLVED

The ms-appinstaller protocol has been disabled.

Copper Contributor

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" button they now see the error below saying the protocol has been disabled. Why is this? Is this permanent? Is there a way to enable it?

 

There's a short mention of this in the docs but it doesn't mention why this is happening or how to enable it. 

Installing Windows 10 apps from a web page - MSIX | Microsoft Docs

 

Is this no longer supported?

 

<html>
    <body>
        <h1> MyApp Web Page </h1>
        <a href="ms-appinstaller:?source=http://mywebservice.azureedge.net/HubApp.msix"> Install app package </a>
        <a href="ms-appinstaller:?source=http://mywebservice.azureedge.net/HubAppBundle.msixbundle"> Install app bundle  </a>
        <a href="ms-appinstaller:?source=http://mywebservice.azureedge.net/HubAppSet.appinstaller"> Install related set </a>
    </body>
</html>

 

 

 

The ms-appinstaller protocol has been disabled. Please ask the vendor to update the weblink. For more information go to aka.ms/ms-appinstaller-disabled

 

appinstaller.png

 

 

57 Replies
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.

Hi @Aditi_Narvekar.

Any update on a timeline for this?  Anywhere we can track progress?

 

Thanks.

Ernie

Hi all, we are actively working to enable the feature as soon as we can. We do not have a timeline yet that we can share externally for when the feature will be enabled again. We'll update this thread and our tech community of the solution soon.
@Dian Could I recommend starting a new thread on this topic led/initiated by you. The fact that there is progress being made is getting lost because it falls after 3 pages of frustration posts in this item.
Just as an fyi, we are not seeing automatic updates work via our workaround.

@Aditi_Narvekar 

 

Can you please explain what is going on with this?

 

My customer in Switzerland does not have this issue and can update the app in the normal manner.

 

Perhaps you can please reinstate the protocol and allow all our app users to update our app, even if for a limited time. 

 

This totally unacceptable and can you please confirm this has been escalated from yourself to others who can sort out this issue.  

 

 

 

 

 

This is completely unacceptable for an installation technology. MSIX team: if you’re not willing to properly support AppInstaller, please put it it out of its misery.

Reilly, while I agree completely with you about the support being unacceptable, the proper action would be to make it work no matter how many band-aids are required until an acceptable replacement is available. For UWP apps the writing may be on the wall anyway. This is starting to feel a lot like Silverlight. I only hope that we get a fix to carry us over till a re-write can be done in another technology. A company that can spend 67.8 BILLION on an acquisition but does not supply the necessary resources to fix an internal problem has lost interest in that product.

@hrb-2 Maybe for UWP. Our UWP line of business App is actually in the Windows Store (well Windows Store for Business), but this was such a simpler solution. And Microsoft pushed the Windows Application Packaging Platform for everything so we have been using it to sideload WPF projects, but NoooOo.. They gotta break it just when things were getting easier to deploy. Unbelievable.. lol actually totally believable.

We are also being affected by this with our packaged and signed WPF .Net Core application. I hope a real resolution is reached soon.

@Aditi Now it has been more than a month - should MS be providing some updates on this issue???
It now has over 14,000 views - given how specific the issues is it would seem unlikely these are accidental occurrences and the impact is growing and being noticed. It is bad enough that the temporary fix of just cutting everyone off is most likely worse than the disease, but not informing folks of any progress on a fix implies a complete lack of progress and caring about the problems your customers are facing.

For anybody that is still having issues with this here is how I temporarily solved this problem.

When my application starts up it checks the version number (manually maintained in my App.xaml) against the version hosted on our webserver. If there is an updated version it downloads a zip file with msix and the generated shell scripts. It then upzips the files and runs the shell script through PowerShell to install the new version.

 

Note that this requires the device be in developer mode because executing the shell script is considered installing from an unknown publisher. I'm sure somebody smarter than me could find a work around that doesn't require developer mode (if so reply so I can make the changes).

Thanks for sharing this information. Are you willing to share your scripts (genericized for security concerns of course) and/or provide further details? Unfortunately, it won't help us much as we were in the early stages of an initial rollout so 90% of our users community would not be able to use this workaround but it may help others with an established user base. This Microsoft created debacle also impacts new installs from the internet which use the same protocol, so we are unable to move forward.

@hrb-2You can see my solution here https://github.com/MicrosoftDocs/msix-docs/issues/59#issuecomment-832260691

It does not use shell scripts (which also means it does not require developer mode) but you should be able to work out how to change that.

 

This is a workaround for a much older bug  feature but it works here too.

 

While we are on the subject, if you are manually editing your appinstaller file and/or your users are doing a lot of patching or installing at the moment, it is worth paying attention to this one as well: https://stackoverflow.com/questions/64381453/appinstaller-xml-issue/67390614#67390614

You might want to try signing the powershell scripts. We looked into doing that (for other reasons) a while back and it made windows significantly happier when it came to uac issues.
This is more important than any other software development feature that Microsoft could possibly provide right now. We have no interest in any new Visual Studio updates, frameworks, or UI ideas until you can provide us with the very basic task of updating our deployed software. The lack of action on Microsoft's part indicates that they do not understand the severity of this problem.