SOLVED

Update process not started lauching the program by shortcut or taskbar-item

Copper Contributor

Hi @all!

We had developed a client program, deploying it by msix (wapproj with VS2019 (16.3.1), build by AzureDevOps/TFS 2017 with MakeAppx.exe). The update-settings in the appinstaller-file are set to automatic update:

 

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

 

Installing works fine. But if an update is required, the msix update window-prompt only appears after  the program was launched by the start-menue. Launching the program by a manuell created shortcut - or taskbar item - does not trigger the update and the program starts without it, running the old version. 

 

The shortcut entries seems to be ok, calling the:

explorer.exe shell:AppsFolder\8bbf065c-eac1-4fca-a02e-6753c5308256_ke2zapfkqzqsw!App

But execute the shell manually the update does not appear, also.

 

Within the program I set up the Windows.Management.Deployment.PackageManager. After starting by shortcut an the update does not appear the old version of our program tells  "PackageUpdateAvailability.Required".

 

Have you got an idea how I can set up desktop-shortcuts and taskbar-items which are able to start the update before starting the (new) program? Is this  maybe a windows or msix bug? And how can I create a desktop-shortcut by the definition of msix?

 

Btw., the program was installed on a PC with Windows 10, Version 1903 (Build 18362.356).

 

The complete appinstaller-File: 

<?xml version="1.0" encoding="utf-8"?>
<AppInstaller Uri="UriForAppInstallerFileChangedForPrivacyReasons/PremiumDrive.package.appinstaller"
Version="1.0.0.0" xmlns="http://schemas.microsoft.com/appx/appinstaller/2018">
<MainBundle Name="8bbf065c-eac1-4fca-a02e-6753c5308256" Version="1.0.0.0"
Publisher="CN=Stieger Software AG, O=Stieger Software AG, POBox=9422, STREET=Hauptstrasse 71, L=Staad, S=SANKT GALLEN, PostalCode=9422, C=CH"
Uri="UriForAppInstallerFileChangedForPrivacyReasons/PremiumDrive.package_1.0.0.0/PremiumDrive.package_1.0.0.0.msixbundle" />
<UpdateSettings>
<OnLaunch HoursBetweenUpdateChecks="0" ShowPrompt="true" UpdateBlocksActivation="true"/>
</UpdateSettings>
</AppInstaller>

6 Replies

@THillebrand 

 

Thanks for reporting this, we are looking into the issue and should follow up shortly.

 

John.

best response confirmed by John Vintzel (Microsoft)
Solution

@THillebrand 


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. 

@Tanaka_Jimha- A user should not be able to bypass the auto update process in an Enterprise LOB application. The majority of the MSIX options appear to support this point of view - We have features to support preventing a user from being able to continue with starting the application if there is an update available. It could be that the last release is creating bad data in the database, so you need to get out a hotfix. If they are launching from the desktop or they have pinned to the taskbar, they will bypass all of the controls.

 

@ChreesM- I have the same opinion on this issue. Automatic check for update process should be started no matter how user starts application. It mean check for update should be performed by clicking on app in start menu, on taskbar button and on desktop shortcut. I opened feature request on MSIX page here.
https://techcommunity.microsoft.com/t5/msix/start-update-process-by-clicking-on-application-taskbar-...

Please upvote for mentioned feature.
Thanks.

@MarosK  - Thank you for starting the request. Until this issue is resolved, one workaround would be to leverage the Package AutoUpdater class to check for an update at a given frequency. You can examine the xml at the remote install location to parse out the new version number, (unfortunately the version # is missing from the api). An alternative to parsing the package xml would be to create a text file during the CD process with the version number in it.

 

using Windows.ApplicationModel;
using Windows.Management.Deployment;


...

private async Task CheckForUpdateAsync() { var update = await _currentPackage.CheckUpdateAvailabilityAsync(); if (update.Availability == PackageUpdateAvailability.Available || update.Availability == PackageUpdateAvailability.Required) { try { _timer.Enabled = false; var packageLocation = GetPackageUrl(); var deploymentResult = await _packageManager.UpdatePackageAsync(packageLocation, null, DeploymentOptions.ForceApplicationShutdown); } catch (Exception ex) { _logger.Info("An error occurred while attempting to update the package: " + ex.Message); } }



        private Uri GetPackageUrl()
        {
            const string mainBundleNodeName = "MainBundle";
            const string uriAttributeName = "Uri";

            var appInstallerUri = Package.Current.GetAppInstallerInfo().Uri.ToString();
            var xmlDoc = XDocument.Load(appInstallerUri);
            var defaultNameSpace = xmlDoc.Root?.GetDefaultNamespace();
            var mainBundleNode = xmlDoc.Descendants(defaultNameSpace + mainBundleNodeName).FirstOrDefault();
            var packageUri = mainBundleNode?.Attributes().FirstOrDefault(x => x.Name == uriAttributeName)?.Value;

            return new Uri(packageUri ?? string.Empty);
        }
        private void GetCurrentPackage()
        {
            try
            {
                var userSecurityId = WindowsIdentity.GetCurrent().User?.ToString();
                _currentPackage = _packageManager.FindPackageForUser(userSecurityId ?? string.Empty, Package.Current.Id.FullName);
            }
            catch (InvalidOperationException)
            {
                _logger.Info("The running application does not have a package identity, which indicates the process is not executing from an installed application.");
            }
        }

        private async void HandleTimedEventAsync(object source, ElapsedEventArgs e)
        {
            if (_currentPackage == null)
            {
                return;
            }

            await CheckForUpdateAsync().ConfigureAwait(true);
        }  

 

1 best response

Accepted Solutions
best response confirmed by John Vintzel (Microsoft)
Solution

@THillebrand 


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. 

View solution in original post