There is one feature in the Universal Windows Platform (UWP) that is not widely known, but it’s extremely helpful when releasing update of your app. It’s the windows.updateTask.

What it is? The updateTask is a special kind of Background Task that you can have in your app. Background Tasks are pieces of code that can be executed on periodic basis, or when the user logs in or out, or when the push notification arrives or in other cases as described on MSDN. For the standard Background Tasks the app needs to be started first and you need to manually register your background task within the app. In case the app is never launched, the background task cannot be registered and is never executed.

And here comes the magic of the updateTask. The class registered as updateTask in package.appxmanifest is executed automatically when Windows Store updates your app with a new version.

Why should I use it?

There is couple of scenarios when automatically executed code once the app is updated is useful:

• app db/files maintenance or migration –  you can update the SQLite db schema before the new version is launched for the first time, or delete/move temp files to a new location.
• re-register classic background tasks, or register new ones – it’s recommended to check in new version of your app if all background tasks are registered properly. What is even more useful, you can register standard background tasks inside the updateTask!
• show notification about new app version – this is probably the most interesting feature that I use in my app Astronomy Picture of the Day. About two months ago I released the first Windows 10 version of my app, previously I had Win8.1 version, and I included update task to show toast notification, that completely new version of my app was just installed! It’s possible that some users had my old version installed and thanks to the updateTask I was able to show them that new UWP version is now available.

The caveats

Just like with other Background Tasks be careful when using the updateTask – it’s not guaranteed that it will be executed at all, or not terminated in the middle. If you plan to add db migration into it, make sure this migration is checked and done after app start as well. The same approach should be used for registering new background task, always check them when the app is started. And with the toast notifications, often less is more. Too many toast notifications could lead to your app being uninstalled, so be careful.

The updateTask is a useful tool, but use it with caution.

How to use it?

First of all the updateTask is supported in all Windows 10 UWP apps and also in Windows Phone 8.1 XAML apps, but not in Windows 8 or 8.1 desktop apps.

When adding classic Background Task to your app it’s recommended to use the package.appxmanifest editor, but strangely the updateTask is not available in the list of extensions. One can only wonder why? Because it can be misused or it’s primarily targeted for OEMs or 1st party apps? Who knows.

For adding the updateTask you need to edit the package.appxmanifest file manually like this:

The Category part is fixed, the EntryPoint part must be the full name of the IBackgroundTask implementation class where the code for your updateTask is located. And just like with other Background Tasks, the updateTask code must be placed in a separate project of type Windows Runtime Component.

This is how the code for your updateTask could look like:

public sealed class UpdateTask : IBackgroundTask
{
    public async void Run(IBackgroundTaskInstance taskInstance)
    {
        BackgroundTaskDeferral deferral = taskInstance.GetDeferral();
        try
        {
            // ensure the periodic agent each time the app is updated
            await BackgroundTaskService.EnsurePeriodicAgent();
            ShowUpdateToast();
        }
        catch (Exception e)
        {
            Debug.WriteLine($"Exception when executing UWP background task {e}");
            if (Debugger.IsAttached) Debugger.Break();
        }
        finally
        {
            Debug.WriteLine("Background agent end");
            deferral.Complete();
        }
    }
 
    private void ShowUpdateToast()
    {
        ToastNotifier updater = ToastNotificationManager.CreateToastNotifier();
        if (updater.Setting != NotificationSetting.Enabled) return;
 
        // create template for the toast message
        IToastImageAndText03 toastData = ToastContentFactory.CreateToastImageAndText03();
        toastData.Image.Src = "ms-appx:///Assets/starry-night.jpg";
        toastData.TextHeadingWrap.Text = AppResources.UpdateMessage;
 
        // send the udpate toast
        ToastNotification toast = toastData.CreateNotification();
        updater.Show(toast);
    }
}

Testing the updateTask

To test your Update Task, you will need to use the Application Deployment tool to install the initial version of your app and then install your updated app using the /update flag, at which point your Update Task will run.

Conclusion

It’s really easy to add to your Windows 10 UWP app short piece of code, that is executed once the app is updated through Windows Store. I’ve not seen any article or blog post describing the usefulness of this feature except this short MSDN documentation. Without knowing that this feature exists, there is no way to find it.

I hope this article helped you make your UWP app even better. If you have any comments or thoughts, just let me know in the discussion below, or just ping me on my Twitter 🙂

In this blog post I’ll show you how simple it is to detect from any regular 3rd party Windows 10 app if any target app is installed on the same device.

The motivation

Typical scenario, you are a publisher with 5 popular apps on Windows Store. User has just installed your App.A and you’d like to know if he has already installed App.B, App.C, etc, and if not, you would like to show Toast notification to promote the other apps you have published.

The solution

I won’t beat around the bush, all you need is the package family name of all apps you want to discover and this method:
Launcher.QueryUriSupportAsync(Uri uri, LaunchQuerySupportType launchQuerySupportType, string packageFamilyName)

This method is part of the Launcher class and the primary goal of this method is to detect, whether target app X supports Uri scheme Y, but due to some oversight or maybe intentionally it can be used for detecting whether any target app is installed on the same device or not. You can use it even for detecting installed Windows 8.1 apps, Windows Phone 8.1 apps or even Edge extensions!

How it works?

private static readonly Uri dummyUri = new Uri("mailto:dummy@seznam.cz");
 
/// <summary>
/// Check if target <paramref name="packageName"/> is installed on this device.
/// </summary>
/// <param name="packageName">Package name in format: "949FFEAB.Email.cz_refxrrjvvv3cw"</param>
/// <returns>True is app is installed on this device, false otherwise.</returns>
public static async Task<bool> IsAppInstalledAsync(string packageName)
{
    try
    {
        bool appInstalled;
        LaunchQuerySupportStatus result = await Launcher.QueryUriSupportAsync(dummyUri, LaunchQuerySupportType.Uri, packageName);
        switch (result)
        {
            case LaunchQuerySupportStatus.Available:
            case LaunchQuerySupportStatus.NotSupported:
                appInstalled = true;
                break;
            //case LaunchQuerySupportStatus.AppNotInstalled:
            //case LaunchQuerySupportStatus.AppUnavailable:
            //case LaunchQuerySupportStatus.Unknown:
            default:
                appInstalled = false;
                break;
        }
 
        Debug.WriteLine($"App {packageName}, query status: {result}, installed: {appInstalled}");
        return appInstalled;
    }
    catch (Exception ex)
    {
        Debug.WriteLine($"Error checking if app {packageName} is installed. Error: {ex}");
        return false;
    }
}

The method returns enum of possible outcomes, either the target app is installed and supports the target Uri scheme, or is installed but does not support it, or is not installed, or in other unsupported state.

Before checking this approach myself I would have expected, that for apps published by other developers it would just return generic Unknown response, if the Uri scheme is not supported or the app is not installed, but it works just fine as shown below.

Sample app

I’ve uploaded simple app on GitHub that checks for installation status of some popular apps and games. This is the result when I run this app on my Windows 10 Desktop machine with Windows 10 build 14393 (Anniversary Update).

F.A.Q.

Does it work on Windows 10 Mobile/Xbox/HoloLens?

Yes

How can I get the package family names to use?

It’s quite easy, just install the app on your machine and open the folder:
C:\Users\<username>\AppData\Local\Packages
Here you can find app data for all your installed apps from Windows Store. The folders here use the package family names.

The only problem here is that you cannot access this folder on Windows 10 Mobile or Xbox, but Universal apps use the same package family name on all platforms.
Note there might be other ways how to detect the package family names for Windows Phone-only apps. If you find them, just let me know!

Do I need any special App Capability? Does it pass Windows App Certification Kit?

No special capability required. No problem with WACK.

Why is this a problem?

First of all Windows Store apps should run in a Sandbox and by design one app should not be able to detect anything about other installed apps.

Since we can detect if other apps are installed, this feature could be easily misused for nefarious purposes like Targeted Advertising, Device Fingerprinting or Behavior Detection.
For instance Bank app can gather information about number of installed games or social networks to profile the target user.
Game developer can gather intel what other popular games are installed on the same machine.
Malware app or library could detect what social network apps is the target user using, etc.

How this could be solved?

If the Windows OS team agrees that this needs to be fixed, this is the solution I can imagine. First there should be option in the App manifest to define Uri scheme detection as public for any app or private for only whitelisted apps. Then these rules should be applied:

• if target app is not installed – return Unknown result.
• if target app is installed and from the same publisher – no change in behavior. I should be able to ask if my apps are installed.
• if target app is installed but does not support target Uri scheme – return Unknown result.
• if target app is installed and has public Uri scheme – return Available result.
• if target app is installed, has private Uri scheme and asking app is whitelisted, return Available result.
• if target app is installed, has private Uri scheme and asking app is not whitelisted, return Unknown result.

Note the same fixes should be applied to File type support detection as well. I’ve not tested it, but I can imagine that the QueryFileSupportAsync method has the same behavior.

Summary

I’ve shown in this blog post that on Windows 10 device it’s really easy to detect if user has Twitter or Facebook or any other app installed, possible issues that this behavior could create and possible solution to solve it in the future.
For more UWP tips – follow me on Twitter 🙂

In this article I’ll show you how you can easily build Windows Store apps using PowerShell, without launching Visual Studio. Specifically how to build signed .appxupload packages that can be uploaded to Dev Dashboard straight away.

First some summary, by Windows Store apps I mean Windows 8, Windows 8.1, Windows Phone 8.1 (XAML) or Windows 10 (UWP) apps. All these apps use .appx package format when building in Debug mode in Visual Studio.
When creating Windows Store package for your app, you typically use these steps:

1. First, if not done previously, you need to Associate App with the Store. Before you can do that you need to login to Visual Studio with your Windows Store Microsoft Account using two factor authentication, typically using verification code on phone or sent to you by email. After that in the first step unique app name is reserved, app name, publisher name and publishers’ signing .pfx certificate is downloaded to you solution and these data are set in your Package.appxmanifest file.

2. Then you need to build the package for Store, this is typically done using the Create App Packages command. In the wizard that shows up it’s possible to select target version, bundle option, architecture and solution configuration and option to include debug symbols. After then the solution is built and packaged.

As you can see this is not exactly easy to do and definitely not suitable for automatic builds on your VSO or TeamCity Continuous Integration server.

Since Visual Studio 2013 I was trying to replicate the process that Visual Studio is doing when building app to Store using the Create App Packages Wizard. From what I found this process consist of several steps:

• msbuild.exe builds the solution in Release mode.
• makeappx.exe creates .appx package based on a map file containing list of all required files.
• signtool.exe signs the appx with my private pfx certificate.
• pdbcopy.exe copies all PDB files related to all dll, exe or winmd libraries without private symbols.
• These PDB symbols are zipped into .appxsym file.
• Signed .appx file together with .appxsym is zipped into .appxupload final file.

Details about these steps are described in this nice article: Create a Windows Store AppX package and sign it

I spent about two days packing all these steps into single PowerShell script file but then I made huge discovery – that when building Windows Store app in Release mode using Visual Studio 2015 msbuild, it automatically builds signed .appxupload file for the Store as well!

I was testing the same commands about year or two ago with Visual Studio 2013 and I am almost sure that VS2013 does not create .appxupload packages just like that.

To sum it all up, what to do to build Windows Store packages using PowerShell? First associate your app with Store using Visual Studio, select your preferred Store package configuration and build the packages at least once using the wizard. After that make sure to save all your changes to the solution and project file. These project settings will be then automatically used when building the solution using PowerShell. Then just grab this script, enter you solution name, run it in the folder with your solution and you are done 🙂

# tools
$msbuild = "C:\Program Files (x86)\MSBuild\14.0\bin\MSBuild.exe"
set-alias msbuild $msbuild
 
# solution settings
$sln_name = "TestSolution.sln"
$vs_config = "Release" 
$vs_platfom = "x86"
 
# call the rebuild method
Write-Host "Building solution`n" -foregroundcolor Green
msbuild $sln_name /t:Build /p:Configuration=$vs_config /p:Platform=$vs_platfom /v:q /nologo

What is even better about this – you can build Store packages without entering your Microsoft Account credentials every time. Note in my case I’m not using appx bundle settings and I need to repeat these steps for ARM and x64 Configuration.

After that only two unsolved tasks remain:

• How to run Windows App Certification Kit from PowerShell and display the results in TeamCity/VSO?
• How to upload the .appxupload package to Store automatically and release it as a new beta version of my app?

The first task might be possible, I’ll try to dig into this soon and post my findings in another article.
The second feature is still not available since there is no public Windows Store REST API for gathering data about apps from Store/Dashboard or publishing new beta builds automatically. If you think just like me that this should be implemented, please vote here in WPdev UserVoice web for this idea, thanks!

In this article I’ll show you few useful tips when developing any Windows 10 UWP app – how to get basic data about current device, operating system and application. You might need all that info for logging or custom app analytics or maybe in a footer of a support mail generated in the app.

The goal – I want to know in my application:

• current OS family – phone/desktop/…
• current OS build number – 10.0.10240.16413
• current OS architecture – x86/x64/ARM
• current App Display Name – Battery Tile for instance
• current App Version – 3.0.2.0
• current Device manufacturer – Nokia
• current Device model – Lumia 1520

Since Windows Phone 8 basically all APIs we used to gather these data have changed, but I’ve done the work for you, here’s a helper class with all these properties:

using Windows.ApplicationModel;
using Windows.Security.ExchangeActiveSyncProvisioning;
using Windows.System.Profile;
...
public static class Info
{
    public static string SystemFamily { get; }
    public static string SystemVersion { get; }
    public static string SystemArchitecture { get; }
    public static string ApplicationName { get; }
    public static string ApplicationVersion { get; }
    public static string DeviceManufacturer { get; }
    public static string DeviceModel { get; }
 
    static Info()
    {
        // get the system family name
        AnalyticsVersionInfo ai = AnalyticsInfo.VersionInfo;
        SystemFamily = ai.DeviceFamily;
 
        // get the system version number
        string sv = AnalyticsInfo.VersionInfo.DeviceFamilyVersion;
        ulong v = ulong.Parse(sv);
        ulong v1 = (v & 0xFFFF000000000000L) >> 48;
        ulong v2 = (v & 0x0000FFFF00000000L) >> 32;
        ulong v3 = (v & 0x00000000FFFF0000L) >> 16;
        ulong v4 = (v & 0x000000000000FFFFL);
        SystemVersion = $"{v1}.{v2}.{v3}.{v4}";
 
        // get the package architecure
        Package package = Package.Current;
        SystemArchitecture = package.Id.Architecture.ToString();
 
        // get the user friendly app name
        ApplicationName = package.DisplayName;
 
        // get the app version
        PackageVersion pv = package.Id.Version;
        ApplicationVersion = $"{pv.Major}.{pv.Minor}.{pv.Build}.{pv.Revision}";
 
        // get the device manufacturer and model name
        EasClientDeviceInformation eas = new EasClientDeviceInformation();
        DeviceManufacturer = eas.SystemManufacturer;
        DeviceModel = eas.SystemProductName;
    }
}

Some comments:

The property DeviceFamilyVersion contains plain string with a long value containing the OS version. All we need to do is convert it back from string to long and convert each short number back to readable format.

The object Package contains lot of useful data including Package Family Name. You might need this property for some future advanced application contracts, so keep this in mind.

The SystemArchitecture property actually tells you the type of the installed package, not the OS architecture, but if you publish all three platform packages for x86, x64 and ARM, it will match the OS architecture.

DeviceManufacturer and DeviceModel might not be defined on custom built PCs. Also on phones the SystemProductName contains the phone name in non-readable format like RM-940_nam_att_200. To convert this name to readable format Lumia 1520 you can use the Phone Name Resolver library.

Here’s a sample of properties gathered on my notebook:

Windows.Desktop
10.0.10240.16413
X64
Info Test
1.1.0.0
ASUSTeK Computer Inc.
N53SN

and here on my dev phone:

Windows.Mobile
10.0.10166.0
Arm
Info Test
1.1.0.0
NOKIA
RM-940_nam_att_200

And that’s all 🙂 If you know any other useful system properties, just let me know.