Recommended way to check that the Windows App SDK is installed

[DominicMaas]

I'm creating an installer for an application that uses WinUI3 (Unpackaged). To avoid having to redownload dependencies that the user already has, I'm trying to determine if there is a way to check if the Windows App SDK is installed on the users PC already? (and ideally what version).

E.g. I can check the current Visual C++ Redistributable by reading the SOFTWARE\\Microsoft\\VisualStudio\\14.0\\VC\\Runtimes\\x64 subkeys.

[castorix]

You can use PackageManager Class with CsWinRT NuGet Package
I tested with FindPackages and I needed a Manifest with requireAdministrator for Admin access (because it enumerates Packages for all users; maybe other methods don't need Admin access...)
Then you can get the version with OpenPackageInfoByFullName + GetPackageInfo

[DrusTheAxe]

That's a a good start but a bit heavier than necessary.

For one, instead of FindPackages to enumerate and wade through every package on the machine you can check for the specific package families via PackageManager.FindPackagesForUserWithPackageTypes(userSecurityId, packageFamilyName, packageTypes). Also, the returned packages have .Id.Version so no need to use OpenPackageInfoByFullName or GetPackageInfo (plus they won't always suffice for other reasons). FindPackagesForUserWithPackageTypes() avoids the need for admin privileges plus it's simple to use and a lot more efficient.

We have more docs and samples planned (https://task.ms/37948391) but that's not available yet so here's some tips until then.

Some C# how to check for a package registered to the current user from a mediumIL unpackaged process:

using Windows.Management.Deployment;

public class WindowsAppSDKRuntime
{
    public static IsPackageRegisteredForCurrentUser(string packageFamilyName, PackageVersion minVersion, Windows.System.ProcessorArchitecture architecture, PackageTypes packageType)
    {
        ulong minPackageVersion = ToVersion(minVersion);

        foreach (var p : PackageManager.FindPackagesForUserWithPackageTypes(string.Empty, packageFamilyName, packageType)
        {
            // Is the package architecture compatible?
            if (p.Id.Architecture != architecture)
            {
                continue;
            }

            // Is the package version sufficient for our needs?
            ulong packageVersion = ToVersion(p.Id.Version);
            if (packageVersion < minPackageVersion)
           {
               continue;
           }

            // Success!
            return true;
        }

        // No qualifying package found
        return false;
    }

    private static ulong ToVersion(PackageVersion packageVersion)
    {
        return ((ulong) packageVersion.Major << 48) |
               ((ulong) packageVersion.Minor << 32) |
               ((ulong) packageVersion.Build << 16) |
               ((ulong) packageVersion.Revision);
    }
}

FindPackagesForUserWithPackageTypes() is better here than FindPackagesForUser() as you can narrow the search to (in our case) just framework or main packages; this avoids matching other types of packages (resource, optional, bundle) which aren't of interest here (and would complicate the logic to avoid false positives).

The userSecurityId parameter is an empty string to use the current/calling user context.

That's the easy part. The tricky part is deciding how to call it.

A properly installed runtime is composed of multiple packages dependent on the system's cpu architecture.

• On an x86 machine: Fwk=[x86], Main=[x86], Singleton=[x86], DDLM=[x86]
• On an x64 machine: Fwk=[x86, x64], Main=[x64], Singleton=[x64], DDLM=[x86, x64]
• On an arm64 machine: Fwk=[x86, x64, arm64], Main=[arm64], Singleton=[arm64], DDLM=[x86, x64, arm64]

The Main + Singleton packages are easy -- their architecture should match the system's cpu architecture e.g. x64 packages on an x64 system.

The Framework package is a little more complex, as x64 systems can run x64+x86 apps and similarly arm64 systems can run arm64+x64+x86 apps.

The DDLM package checks are similar to the Framework's except PackageType=main, the packagefamilyname differs and multiple different packagefamilynames could be applicable (due to DDLM's unique naming scheme. See MSIXPackages.md).

So the checks are more like

public static bool IsRuntimeRegisteredForCurrentUser(PackageVersion minVersion)
{
    ProcessorArchitecture systemArchitecture = DetectSystemArchitecture();

    return IsFrameworkRegistered(systemArchitecture, minVersion) && 
           IsMainRegistered(systemArchitecture, minVersion) &&
           IsSingletonRegistered(systemArchitecture, minVersion) &&
           IsDDLMRegistered(systemArchitecture, minVersion);
}

private static ProcecssorArchitecture DetectSystemArchitecture()
{
    ...see the call to IsWow64Process2() and use of the result...
    ...as per `IsPackageApplicable()` in [install.cpp](https://github.com/microsoft/WindowsAppSDK/blob/main/installer/dev/install.cpp) line 99-116...
    ...WARNING: Use IsWow64Process2() to detect the system architecture....
    ...         Other similar APIs exist but don't give reliably accurate results...
}

private static bool IsFrameworkRegistered(ProcessorArchitecture systemArchitecture, PackageVersion minVersion)
{
    // Check x86
    if (!IsPackageRegisteredForCurrentUser(global::Microsoft.WindowsAppSDK.Runtime.Packages.Framework.PackageFamilyName, minVersion, ProcessorArchitecture.X86, PackageTypes.Framework))
    {
        return false;
    }

    // Check x64 (if necessary)
    if ((systemArchitecture == ProcessorArchitecture.X64) || (systemArchitecture == ProcessorArchitcture.Arm64))
    {
        if (!IsPackageRegisteredForCurrentUser(global::Microsoft.WindowsAppSDK.Runtime.Packages.Framework.PackageFamilyName, minVersion, ProcessorArchitecture.X64, PackageTypes.Framework))
        {
            return false;
        }
    }

    // Check arm64 (if necessary)
    if (systemArchitecture == ProcessorArchitcture.Arm64)
    {
        if (!IsPackageRegisteredForCurrentUser(global::Microsoft.WindowsAppSDK.Runtime.Packages.Framework.PackageFamilyName, minVersion, ProcessorArchitecture.Arm64, PackageTypes.Framework))
        {
            return false;
        }
    }

    return true;
}

private static bool IsMainRegistered(ProcessorArchitecture systemArchitecture, PackageVersion minVersion)
{
    return IsPackageRegisteredForCurrentUser(global::Microsoft.WindowsAppSDK.Runtime.Packages.Main.PackageFamilyName, minVersion, systemArchitecture, PackageTypes.Main);
}

private static bool IsSingletonRegistered(ProcessorArchitecture systemArchitecture, PackageVersion minVersion)
{
    return IsPackageRegisteredForCurrentUser(global::Microsoft.WindowsAppSDK.Runtime.Packages.Singleton.PackageFamilyName, minVersion, systemArchitecture, PackageTypes.Main);
}

private static bool IsDDLMRegistered(ProcessorArchitecture systemArchitecture, PackageVersion minVersion)
{
    ...similar to IsFrameworkRegistered() but the packageFamilyName is more complicated...
    ...and no predefined constant currently available...
    ...for more details see https://github.com/microsoft/WindowsAppSDK/blob/main/specs/Deployment/MSIXPackages.md...
}

That covers the basic detection scenario. Additional logic's needed to detect if the runtime is provisioned for all users, to do the above from an AppContainer, and/or do it from a packaged MediumIL process.

[amtopel]

Does Microsoft recommend that we do all this, or just download the installer and let it decide what to do? Because none of this is mentioned on the deployment page here: https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/deploy-unpackaged-apps.

[DarranRowe]

For an application itself, you really don't have to worry about any of this. As the original poster wrote, they were writing an installer.

[DrusTheAxe]

if there is a way to check if the Windows App SDK is installed on the users PC already? (and ideally what version)

Yes, but it's a little complicated and depends on some details you didn't specify.

How do you define "installed"? The key questions:

1. Registered for the current user, another user or all users?
2. Is the process doing the check packaged or unpackaged?
3. Is the process doing the check running in an AppContainer, MediumIL or Elevated?
4. What architecture(s) does your app need to run?

[DominicMaas]

I'll take a look at your other comment later today.

1. In this case, all users (the app is installed within Program Files, where all users can access it via a start menu shortcut)
2. Unpackaged process (likely a c++ process spun off InnoSetup running as admin to avoid having to script within InnoSetup)
3. I believe Elevated?
4. ARM64 & X64

[DrusTheAxe]

1. In this case, all users

In that case you want WinAppSDK's packages to be "provisioned".

For instance, when you run the installer it will register packages for the current user and, if running elevated, also provision the package for all users via pkgmgr.ProvisionPackageForAllUsersAsync(). Provisioning a package requires admin privilege i.e. elevation; per-machine operations (read or write) usually do. Users can alter their own state and view, but machine-wide access requires more rights, thus, admin privilege aka elevation.

pkgmgr.FindPackagesForUser*() tells if you a package is registered for a user. The easy way to check if a package is provisioned is via pkgmgr.FindProvisionedPackages() e.g.

FOREACH p IN pkgmgr.FindProvisionedPackages()
    IF AreEqualIgnoreCase(p.Id.PackageFamilyName, pkgfamilyname)
        return true
return false

where 'pkgfamilyname' is the package family name for the various WinAppSDK packages.

NOTE: FindProvisionedPackages() has no overloads to provide filtered results e.g. no pkgmgr.FindProvisionedPackages(pkgfamilyname, PackageType.Main). If that interests you please open an Issue with your feedback/ask. Thanks!

One potential caveat, FindProvisionedPackages() first appeared in Windows 10.0.19041.0 (aka 20H1). Are you looking to run on older systems?

3. I believe Elevated?

That's good. If you're doing per-machine operations you need admin privileges to use the provisioning APIs.

[DominicMaas]

I'll likely want to run on older systems, but I can version check that API in the installer (need to do some more thinking).

So, with the FindProvisionedPackages(), I can see the Main, Singleton, and DDLM packages provisioned on my system, but not the framework. I presume the framework package will only show up under installed packages (for the user)?

[DrusTheAxe]

FindProvisionedPackages(), I can see the Main, Singleton, and DDLM packages provisioned on my system, but not the framework

Correct.

There's 2 mechanisms how one can provision a package:

1. dism.exe /Add-ProvisionedAppxPackage
2. PackageManager.ProvisionPackageForAllUsersAsync()

They're mostly equivalent e.g. both require admin privilege. The more notable differences:

• DISM is an executable vs ProvisionPackagesForAllUsersAsync() is a WinRT API
• DISM can provision to the online (running) system or an offline image vs ProvisionPackagesForAllUsersAsync() can only provision to the online (running) system
• DISM can provision framework packages (recently¹) vs ProvisionPackagesForAllUsersAsync() can't

If WindowsAppRuntimeInstaller.exe is running elevated it calls ProvisionPackagesForAllUsersAsync() to provision packages. Hence the reason FindProvisionedPackages() sees the other packages but not the framework.

But that's OK. Windows won't remove a framework package if another package depends on it. So as long as a Main, Singleton and/or DDLM package (or any other package) is provisioned a compatible Framework package must be present. This is effectively an indirect or implicit provisioning.

¹ Historically framework packages couldn't be provisioned. DISM was updated to enable this recently (Win11) but ProvisionPackagesForAllUsersAsync() wasn't updated to match :-( I've added an item to our backlog to address this inconsistency https://task.ms/39439836.

NOTE: 'Backlog' means 'Future, someday, probably, no ETA'. If this interests you please share your feedback by filing a new Issue. Thanks!

[DominicMaas]

Awesome. Thank you very much!