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

Start update-process by clicking on application taskbar button or desktop shortcut
 01-05-2020
11 Comments (11 New)
In the backlog

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

25 Upvote
Comment
Comments
Microsoft
Status changed to: In the backlog
 
Occasional 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.  :( 

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

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.

Regular Visitor

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!

 

Frequent Visitor

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.

Regular Visitor

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

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

 

Regular Visitor

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

 

Senior Member

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

Senior Member

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

Similar Ideas
No similar ideas