Document that App Installer OnLaunch updates don't fire from desktop shortcuts or taskbar#477
Open
RDMacLachlan wants to merge 3 commits into
Open
Conversation
…shortcuts or taskbar App Installer automatic OnLaunch update checks are only triggered when an app is launched from the Start menu (including tiles), not from a desktop shortcut or a taskbar item. This is by design but was undocumented, leading to confusion (GitHub issue MicrosoftDocs#59). - update-settings.md: add an IMPORTANT note under OnLaunch explaining the by-design limitation and pointing to the code-based update workaround. - auto-update-and-repair--overview.md: add a NOTE in Automatic updates with the same limitation and workaround link. - non-store-developer-updates.md: add a TIP framing code-based updates as the workaround for the shortcut/taskbar limitation, linking back to OnLaunch. Resolves AB#24544290 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
|
Learn Build status updates of commit 86d78d3: ✅ Validation status: passed
For more details, please refer to the build report. |
DrusTheAxe
reviewed
Jul 7, 2026
| Windows apps will use their App Installer URI path to check for Windows app updates, however if the App Installer URI is inaccessible the Windows app will check for updates using the UpdateURIs, attempting to connect to each before attempting the next. The first App Installer file to be accessible will be validated against checking for any new Windows app updates. | ||
|
|
||
| > [!NOTE] | ||
| > On-launch update checks are triggered only when the app is launched from the Start menu (including Start menu tiles). By design, they are **not** triggered when the app is launched from a desktop shortcut or a taskbar item. To check for updates regardless of how the app is launched, update the app from your code. For more information, see [Update non-Store published apps from your code](../non-store-developer-updates.md). |
There was a problem hiding this comment.
Don't they also fire when launched via AppExecutionAlias?
e.g. goto command line and type "savant", "winget", etc and .appinstaller rules kick in
| > [!IMPORTANT] | ||
| > **OnLaunch** update checks happen only when the app is launched from the **Start menu** (including Start menu tiles). By design, they are **not** triggered when the app is launched from a **desktop shortcut** or a **taskbar** item—those launches start the currently installed version without checking for updates. This behavior reduces friction for task-focused launches. If you need updates to be checked regardless of how the app is launched, check for and apply updates from your app's code. For more information, see [Update non-Store published apps from your code](../non-store-developer-updates.md). | ||
|
|
||
| - **HoursBetweenUpdateChecks**: An integer that indicates how often (in how many hours) the system will check for updates to the app. “0” to “255” inclusive. The default value is 24 (if this value is not specified). For example if HoursBetweenUpdateChecks = 3 then when the user launches the app, if the system has not checked for updates within the past 3 hours, it will check for updates now. |
There was a problem hiding this comment.
Phrasing of the 1st sentence ("An integer...") is a little odd.
HoursBetweenUpdateChecks="n" means "if the check hasn't occurred in >=n hours
SUGGESTION: Wordsmith phrasing
| This article provides examples that demonstrate how to declare the `packageManagement` capability in your package manifest and how to apply an update from your code. The first section looks at how to do this if you're using the App Installer file and the second section is about how to do so when **not** using the App Installer file. The last section looks at how to make sure your app restarts after an update has been applied. | ||
|
|
||
| > [!TIP] | ||
| > Updating from your code is also the recommended way to handle App Installer automatic updates that don't fire from every launch entry point. App Installer [OnLaunch update checks](app-installer/update-settings.md) are triggered only when the app is launched from the Start menu, not from a desktop shortcut or a taskbar item. If your app can be launched from those entry points and you still need it to stay current, check for and apply updates from your code as shown below. |
There was a problem hiding this comment.
That's 3 out of...lots of possible entry points / reasons
- FTA
- protocol
- AppExecutionAlias
- ...
Is StartMenu the only absolute-yes and anything else - mentioned or not - is a no?
| This article provides examples that demonstrate how to declare the `packageManagement` capability in your package manifest and how to apply an update from your code. The first section looks at how to do this if you're using the App Installer file and the second section is about how to do so when **not** using the App Installer file. The last section looks at how to make sure your app restarts after an update has been applied. | ||
|
|
||
| > [!TIP] | ||
| > Updating from your code is also the recommended way to handle App Installer automatic updates that don't fire from every launch entry point. App Installer [OnLaunch update checks](app-installer/update-settings.md) are triggered only when the app is launched from the Start menu, not from a desktop shortcut or a taskbar item. If your app can be launched from those entry points and you still need it to stay current, check for and apply updates from your code as shown below. |
There was a problem hiding this comment.
not from a desktop shortcut
What kind of desktop shortcut scenario?
- manifested windows.shortcut extension?
- manifested windows.dataShortcut extension?
- Not-manifested .LNK file specifying activation via AUMID?
- Not-manifested .LNK file specifying activation via AppExecutionAlias (e.g. "wt.exe")?
- Not-manifested .LNK file specifying a non-executable file to be handled per FTA (e.g. "c:\foo\bar.txt" launching a packaged text editor with a manifested .txt FTA)
- ...
Addresses DrusTheAxe review: reword the HoursBetweenUpdateChecks description so it reads as the minimum number of hours between checks (a throttle) rather than a fixed cadence. On launch, a check occurs only if at least that many hours have passed since the last check. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3d27fb29-0162-474f-8e83-e7cc06dfe11c
Contributor
|
Learn Build status updates of commit 3612e68: ✅ Validation status: passed
For more details, please refer to the build report. |
Addresses DrusTheAxe review: the TIP implied desktop shortcut and taskbar were the only launch entry points that skip OnLaunch update checks. Reword to say checks don't run from every entry point, using shortcut/taskbar only as examples, without asserting which entry points do trigger a check. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3d27fb29-0162-474f-8e83-e7cc06dfe11c
Contributor
|
Learn Build status updates of commit 84eb1d1: ✅ Validation status: passed
For more details, please refer to the build report. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resolves the doc gap behind Azure Boards work item AB#24544290 and GitHub issue #59.
Problem
App Installer automatic
OnLaunchupdate checks are only triggered when an app is launched from the Start menu (including tiles). By design, they are not triggered when the app is launched from a desktop shortcut or a taskbar item, so those launches start the currently installed version without checking for updates. This behavior was confirmed by-design but undocumented, which caused confusion for developers using App Installer auto-update settings.Changes
app-installer/update-settings.md— Added an[!IMPORTANT]note under OnLaunch describing the by-design limitation and pointing to the code-based update workaround.app-installer/auto-update-and-repair--overview.md— Added a[!NOTE]in the Automatic updates section with the same limitation and workaround link.non-store-developer-updates.md— Added a[!TIP]framing code-based updates as the workaround for the shortcut/taskbar limitation, linking back to the OnLaunch settings.ms.dateon the edited files.