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

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

Upvotes

Upvote

 Jan 05 2020
25 Comments (25 New)
Working on it

Currently MSIX deployed desktop application (eg. Winforms or WPF) are automatically updated only when app is launched by Start menu item. When user launch app by clicking on app taskbar button or on app desktop shortcut, check for update is not launched. So if new version is available and user runs app always by shortcut or by taskbar button, new version is never detected and thus never installed. This is wrong, because users strongly prefer runs app by desktop shortcut or by taskbar button. Thus I ask to implement checking for update also by clicking on desktop shortcut and on taskbar button.

More description you can find on GitHub issue
https://github.com/MicrosoftDocs/msix-docs/issues/59

Thanks

Comments
Microsoft
Status changed to: In the backlog
 
Brass Contributor

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.  :( 

Copper Contributor
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.
Copper Contributor

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.

Copper Contributor

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!

 

Copper Contributor

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.

Copper Contributor

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>
 
 
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...
Iron Contributor

@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>

 

Copper Contributor

@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 :)

 

Iron Contributor

@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.

Copper Contributor

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 :\

Copper Contributor

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.

Microsoft
Status changed to: Working on it
 
Copper Contributor

Is there an estimated timeline (worst case)?

Copper Contributor

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.

Brass Contributor

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

Copper Contributor

@John Vintzel  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.

Copper Contributor

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.

Microsoft

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.

Copper Contributor

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!!!!

Copper Contributor

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

Iron Contributor

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.

Microsoft

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

Copper Contributor

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?

Copper Contributor

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,