Start update-process by clicking on application taskbar button or desktop shortcut

[StephenJeffreyWhite]

It would be extremely beneficial if you could have this implemented. A lot of us who have switched over from ClickOnce and/or are looking to take advantage of MSIX for deployment for business apps to continue to see the updater work with regular desktop / taskbar shortcuts.  It should also be noted that using a work around and calling the package manager within the application seems to be a lot slower than having the deployment service handle it outside the app.  😞 

[JohnGroft]

Looking to switch over from ClickOnce. Not being able to guarantee that the user has the latest version EVERY time they launch the app is a potential show-stopper. I can understand this not being in place given that MSIX's heritage is UWP apps. However, now that it is being used for desktop applications as well, there should at the very least be an option to force an update every time a user launches the app - regardless of how that launch is initiated.

[dancra]

I support WPF applications and I agree with previous comments. 

Consider this use case: Suppose I have a critical bug fix in a mission-critical application that leverages MSIX. I need my end users to receive the fix the next time they run the application. Some of my end-users run the WPF application via desktop shortcuts, some via tiles (real world scenario). 

Using MSIX I cannot guarantee all of them will receive that bug fix. Even worse, some of them may receive the fix and others may not depending on how they fire up the application. This would cause me a lot of trouble and wasted time determining what is going on.

[thibaudcomte]

Hello,

This is a major no-go to us as well.
Do you have any roadmap details to share regarding auto-update from taskbar and desktop shortcut ?
What about older OSes with MSIX Core ? Will MSIX Core support those use cases as well ?

Thank you!

[atava85]

It is almost unbelievable that updates are allowed from the Start Menu but not from the (infinitely more used) Desktop shortcuts and taskbar buttons. I'm saying this neutrally, as in: "if you told me something like this would happen, I wouldn't believe it."

As said above, there are business apps in play here and sometimes time-critical updates. 
This is not only technology which we've always had before (e.g. ClickOnce), but also very basic one.
There is absolutely no theoretical justification for omitting updates for shortctuts and the taskbar, or even for splitting the update process in two, leaving one use case (ironically, the much preferred one) in complete darkness regarding one's application's updating.

Also, asking users to start the application, then close it and then start it again to check if the update went fine is very counter-intuitive and unprofessional.

[thibaudcomte]

Ok so we've figured out that the update mechanism works when app is launched from the taskbar or desktop shortcut (and start menu obviously) if the package includes the following declaration :

    <UpdateSettings>

        <OnLaunch

            HoursBetweenUpdateChecks="0" />

    </UpdateSettings>

https://docs.microsoft.com/en-us/uwp/schemas/appinstallerschema/element-onlaunch

But leaving just 

    <UpdateSettings>

        <OnLaunch />

    </UpdateSettings>

Won't update if not started from the start menu...

It seems to us the official documentation is lacking in that area...

[MarosK]

@thibaudcomteI have HoursBetweenUpdateChecks="0" in my Package.appinstaller project file and it do not start update process if app is launched from desktop shortcut or taskbar button.

<UpdateSettings>
     <OnLaunch HoursBetweenUpdateChecks="0" ShowPrompt="true" UpdateBlocksActivation="true"/>
     <ForceUpdateFromAnyVersion>true</ForceUpdateFromAnyVersion>
/UpdateSettings>

[thibaudcomte]

@MarosK,

The documentation reads : 

Setting the ShowPrompt="true" attribute currently shows a prompt for UWP applications but not for desktop applications that have been packaged in a Windows app package (that is, desktop applications that use the Desktop Bridge). For desktop applications, this functionality provides a silent update; the same default functionality provided by the OnLaunch element.

We don't have this attribute in our package file, but the app is still updated (the new app features are available when the app is launched and an update available). As made clear by the documentation, the update is silent for Desktop Bridge apps. But the update works 🙂

[MarosK]

@thibaudcomtemy application is WPF compiled under .Net Core and automatic update procedure is not started when app is launched by clicking on app desktop icon or task bar button.

[aesalazarln]

I wish I read this a week ago before I started working on the change over from ClickOnce to AppX/Msix.  This is a complete show stopper for us.  We need the app to check every time it is launched if an update is available.  If there is, IT SHOULD UPDATE BEFORE even launching the app, not after.  I am floored that cannot be done. 

I see options 

UpdateBlocksActivation

to force but that seems to only work on the latest Win10 builds.  Why on earth didnt MS update ClickOnce to support .net core so we can keep the same UX.

Might have to see if Squirrel.Windows is still a viable option 😕

[florisverhoeven]

I'm using MSIX to update a .NET Core WPF application. In that context, this behaviour is very strange and took a long while to try to figure out what's going wrong. Launching the app from a shortcut or from the Start Menu should all result in the exact same update behaviour. 

Especially when adding the following line to the .appinstaller file:

<OnLaunch HoursBetweenUpdateChecks="0" ShowPrompt="true" UpdateBlocksActivation="true"/>

Does anyone have a decent workaround? Manually checking versions and triggering update processes kind of defeats the purpose of the whole mechanism, I would think.

[Marcel_Wiederkehr]

Is there an estimated timeline (worst case)?

[JeffRichardson]

I too would like to say how important it is in an enterprise environment to have the app check for updates no matter how the app is launched.  The MSIX should be able to create shortcuts in all of Windows's special folders (Taskbar, StartMenu, Desktop, Startup, SendTo,...).  Special attention to the SendTo folder is required in order to pass the selected file's path from File Explorer to the app's StartupEventArgs for processing.

Creation of these shortcuts should be declarative in the MSIX so that they all can be removed on uninstall.

[mmmoore2288]

Not to ruin the mood here, but I just want to point out that this is also an issue with ClickOnce for .NET Core 3.1 and above, so any hope of migrating back to ClickOnce doesn't save you either.

See the official response from Microsoft here:

ClickOnce Application not updating if run from pin to Taskbar - Visual Studio Feedback

Spoiler alert, they say they're not fixing it for ClickOnce...

[MichalKala1991]

@jvintzel  Hi, any news on this? Latest status "working on it" is 8 months old. As has been stated by many - this is quite critical feature. We wish to migrate to MSIX, but we need to ensure applications will auto update regardless of which shortcut does user use. Thanks in advance.

[sungaila]

Any updates on this? We would love to package a WPF app with MSIX and make use of this automatic updates feature.

However, enforcing updates works for the start menu only (and not for the taskbar or desktop shortcuts). This makes migrating to MSIX pretty pointless and we will stay with our custom deployment tools.

Whoever decided on the Windows team to have different update behaviors depending on where you launch the app ... I just can't believe how you can make this horrible UX decision.

[Roy_MacLachlan]

Thank you everyone for your interest in automatic updating and ensuring that updates are performed no-matter how your app is launched. This work is currently in our backlog.

[christophekeller]

I'm in the process of migrating to MSIX and have also experienced this bug. Any updates on this? It's been nearly three years that this bug was discovered!!!!

[Wen_Li]

Just want to follow up on the issue. Any updates on this? It's 2023 now. 

[MarosK]

Unbelievable. I open this issue on January 2020, more than three years ago. @John Vintzel two years ago changed status to Work on it. Now we are in 2023 and nothing happend. Issue is still not solved. That's the way how Microsoft support their loyal developers.

[Sushant_Bansal]

Hello everyone,

I'm a member of the MSIX team and I'm actively investigating the reported issue. Despite my efforts on multiple machines, I wasn't able to reproduce the problem. Could you kindly confirm if you are still encountering this issue? If so, it would be incredibly helpful if you could provide details about the specific Windows build you are using.

We want to assure you that Microsoft is dedicated to offering unwavering support to the MSIX developer community, and we're deeply invested in resolving this matter. 🙂

Thank you for your patience and for being a part of our community.

Best regards,

Sushant Bansal

MSIX Team

[Zero_Circles]

Yes, this is absolutely still a problem. Seems odd that it couldn't be reproduced, as I've needed to work around this issue on every machine I've used for the past three years. Literally pick any specific Windows build from the past couple of years and it should occur.

What specific Windows build was being used when the issue couldn't be reproduced?

[Wen_Li]

Sushant, 

We are currently using Windows 10 Version 21H2 (OS Build 19044.3324). This isuee has been there for a while and I hope it can be fixed as soon as possible. 

Thanks,

[Alexander2210]

How can this still be in the "Working on it" status after 3 years?

Can we get any sort of update or commitment from Microsoft on this?