-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update-Process not started launched by Desktop-Shortcut or Taskbar-Item #59
Comments
When the update doesn't work when launching from the Taskbar, is this happening Can you please share your AppInstallerFile and OS version? Thanks, |
Hi Tanaka, The Windows 10 Version is 1903 (Build 18362.356). |
Sorry, but I have a meeting tomorrow.... |
@Huios We are also having this problem. For example, if myself or another user launches the app from the start menu or a live tile, the update process runs and checks for updates and lets them know they have an update for the app that they need to install before they can proceed. This happens regardless of whether or not they are using the app installer that we have on our test environment (local network file server) or the one that we use for production (Azure blob). This also happens regardless of whether or not it is the first run or a subsequent run after the update has been made available. However if they open the app from either a task bar or desktop shortcut, the updater doesn't show up. Windows also doesn't seem to download and queue up the app for installation in the background. When they restart the app it is still the old version. We have to get them to either use the start menu or live tile short cut to get the app to update. It seems almost like the UWP container is getting bypassed by using traditional shortcuts. OS version - Windows 10 1903 App installer file snippet:
|
@Huios If this isn't the proper place to raise this issue, could you please provide me with guidance as to where to bring it up? This is going to cause a lot of problems with people running on outdated versions of our software since we have a lot of users who rely upon desktop shortcuts and task bar icons for launching their apps. |
Sorry for the delay here, we're still investigating the issue. I'll loop back as soon as we have an update on what's causing this and any potential workarounds. |
After following up with our team, it turns out current implementation does not trigger the update from taskbar and desktop shortcuts by design. The reasoning was that many of those types of app launches are for completing a task so they were trying to reduce friction for the user. Updates were limited to launches from the Start menu or live tiles. We've added your ask as a feature request for upcoming releases. |
@Huios Thanks for looking into that for us. I am considering a couple of workarounds right now until this feature is supported. I find the design decision a little strange since most users still use desktop shortcuts in my experience. However, from the way you have worded it, it sounds like it may have been also due to some programming and architectural considerations. So I can understand why it's not as "simple as it seems" (nothing ever is, right? 😉) In the meantime, I'd recommend that you should consider updating the documentation for AppInstaller to point out that traditional shortcuts are not supported at this time. Aside from the obvious work-around of telling users to launch from the start menu or live tiles, do you know if there are any Windows 10/RT APIs that we can leverage to check for updates while the app is launching to at least have Windows queue up an update and then inform the user that the app is updating? I know there is one for the store, but it isn't clear if that API works for sideloaded apps. I don't mind programming in something like that. We're just concerned that many users will be forgetful and launch from their desktop/taskbar shortcuts when there is an update available and the background task hasn't caught the update yet for them. If you don't recommend using any APIs or there isn't any way to do such a thing, I can see about using KACE (which we have) to help automate deployment, but I'd rather not go that route if there are some other means. |
I agree dragnilar! So, please add the feature with a high prio. |
@dragnilar you can consider using the PackageManager.UpdatePackageAsync API To use it you need the package management capability in your package - <rescap:Capability Name="packageManagement" /> We're working on getting this documented better. In the meantime, here's sample C# code on using the API to update your package: `private async void CheckUpdate(object sender, TappedRoutedEventArgs e)
|
@Huios That API is exactly what I needed. Thank you for pointing that out to me. It works well with the splash screen in our WPF app, so we're now covered on both sides (start menu and traditional shortcuts). We can definitely live with this. Thanks for the help! |
You're welcome @dragnilar , glad I was able to help! |
Hi @dianmsft, I also ask to fix this shortcoming. We invest a lot of time and resource to switch from our old install and update procedure to new MSIX installation and automatic update procedure. We estimated that new way of installation and update of apps provided by Microsoft will cover all ordinary scenarios. Now we are in situation where update process is not working using standard app launch method (desktop shortcut, taskbar button). To be a honest, our users strongly prefer desktop and taskbar over start menu. Proposed workaround to check for new version inside app is not acceptable, because we estimate and require that MSIX standard update procedure have to work in any ordinary circumstances. Run app by desktop shortcut and taskbar button is standard way how to work in Windows. Please reopen this issue and ask team to fix it. |
@Huios : Can you please provide a link to the feature request you mentioned above has been created for this issue. So I can go and upvote. I cannot seem to find the feature request/"idea" here : https://techcommunity.microsoft.com/t5/msix/idb-p/MSIXIdeas |
@THillebrand, @dragnilar and @biilmann-orifarm, I created new idea in Microsoft Tech Community MSIXIdeas page which describe request to run update-process starting app by taskbar button, desktop shortcut. Please upvote for it if you feel that it is important. Thanks a lot. |
@dragnilar: I'm facing a similar problem here. We have a WPF app that we recently migrated to target .NET Core 3.1 - and now I'm trying to package and deploy that app using MSIX, along with an AppInstaller file for auto-updates. I just recently discovered this "by-design-feature" re. not getting updates when started from a desktop shortcut. Did you manage to call that API which @Huios mentions above, from .NET Core code? Or how did you go about adding code that checks for updates? UPDATE: Aha - via this blog post I just found out about Microsoft.Windows.SDK.Contracts. It seems I can use the API mentioned above this way. I'm going to give that a try and see if does the trick. |
Yep, the API that @Huios provided definitely worked. And that library that is mentioned in the blog post is the one I used. I noticed that its a little slower than the auto updater that is embedded in Windows 10 if you call it within the program/package that is being updated. I haven't really had the time to experiment with it further to see if there is a way to get it perform as quickly. One thing I found that helps is if you use it to check for updates before running the UpdatePackagesAsync method since it can throw exceptions if there are no updates available. For example:
You can use that to determine whether or not it is "safe" to use the UpdatePackageAsync method on the PackageManager class. Edit: I also posted a solution about this on Stackoverflow when I asked on there if anyone else had a work around. It's effectively a recap of everything on here. |
@dragnilar : Excellent. Thanks for the info and update. I'll dig more into this now that I (finally) got my code signing certificate to work on our build server. |
Hi @Huios |
@SimoneBWS I was facing the same problem but couldn't find a way to restart the app after an update. Instead i solved it this way: if an update is available download the .appinstaller, run it and exit the application.
Edit:
|
Hi @Dreiundzwanzig, if you are interesting on this topic, please upvote for feature request on MSIX team pages on Microsoft Tech Community site. |
will your approach to directly launch appinstaller work if user has no Administrator rights, thus user can't elevate process to admin level? In other words could be appinstaller launch without administrator rights? |
I actually like this as a better approach than the one I came up with; opening up the app installer using the string seems to be pretty much the same thing that Windows does when you launch from the start menu. 👍 The only thing I might add is that if you are using Dot Net Core, it looks like you'll need to create a process object with a process start info that specifies to use shell execute. Otherwise you'll get an exception saying "File Not Found":
|
Sorry for the late reply: |
Just because it took me hours to get working, and because a lot of the versions of this written above seem to be broken (in many cases this appears to be due to bugs introduced since they were written), I thought I might just add in my version which is currently working as of this date:
Please note that this.Version is a System.Version which can be gotten using:
I refuse to use the PackageVersion class because it is totally redundant, and does not even have a ToString implementation. Edit: updated the code to reflect the fact that the appinstaller protocol has been disabled |
@DuncanStone Thanks for sharing your workaround. A - not very elegant - workaround is changing the Process.Start... line to:
|
@MichaelBakkerDP actually that is a new issue, this post was written long before the protocol was disabled. I do apologise however as I posted a link to this in the thread for the protocol issue and forgot to update this post to reflect my most recent changes. I will correct this immediately |
For me, Package.Current.GetAppInstallerInfo() is returning null. Any idea why? |
Pacakage.Current is null if you are running the main project code in the debugger. If you want to debug this code you need to set the .wapproj project as the startup project and run that. This will deploy it as a package. Yes this can be a major pain. My solution for everyday use is simply to comment out the whole contents of the CheckForUpdates function with #if !DEBUG if you are not directly testing that function. |
|
A workaround is not a final solution. It's clearly a feature missing / bug for the current behavior. |
@supershopping I completely empathize. It's disappointing that they are still "working on it": I know the work around worked for us, but we had to ditch MSIX. This was due to the obvious lack of resources Microsoft has been dedicating to the product. It is unfortunate that they are dedicating even less these days. Satya Nadella is starting to seem like he is not doing a respectable job as a leader. |
Hi @ALL!
I have a msix package with an appinstaller, setting the UpdateSettings:
Building, installing an execute this by using the Start-Menu-Entry seems to be fine. The Update-Window appears (and is closed if no update is pending) and the program starts.
But if I create and use a shortcut or a Taskbar-Item, the Update don't appear. The program starts directly with the old version.
The shortcut seems to be correct created (using the PackageFamily and the Id).
Same using the shell command:
Does anybody know how to fix this? I want a shortcut and a taskbar item which calls the update process before starting the program.
The text was updated successfully, but these errors were encountered: