Is Windows App SDK Full Version Number (e.g. 1.5.4) stored somewhere in the assemblies/DLLs?

[TommiGustafsson-HMP]

A simple question:

Is the Full Version Number (e.g. 1.5.4) of Windows App SDK stored somewhere in the assemblies/DLLs?

I only found 1.5 but not 1.5.4. Is the third digit stored somewhere in the assemblies/DLLs so that I can fetch it in C#?

Edit: AssemblyInfo.cs has only these:

using System.Reflection;

[assembly: AssemblyCompany("Microsoft Corporation")]
[assembly: AssemblyProduct("Windows App SDK")]
[assembly: AssemblyCopyright("Copyright (c) Microsoft Corporation. All rights reserved.")]
[assembly: AssemblyFileVersion("1.5")]
[assembly: AssemblyVersion("1.5.0.0")]

[DarranRowe]

Why do you want to know this.
Version checking is always a problem, since it is always so easy to mess up. If you want to check for specific features, then the contracts are available to check. You can also check for methods too.

    void MainWindow::myButton_Click(IInspectable const&, RoutedEventArgs const&)
    {
        auto has_winui_contract = Windows::Foundation::Metadata::ApiInformation::IsApiContractPresent(L"Microsoft.UI.Xaml.WinUIContract", 2);

        if (has_winui_contract)
        {
            myButton().Content(box_value(L"True"));
        }
        else
        {
            myButton().Content(box_value(L"False"));
        }
    }

The above is an example, showing a check for version 2 of the WinUI contract.

If you want to force a certain minimum version, just make sure that the version you want as the minimum is the one referenced as the NuGet package. For unpackaged applications, the auto bootstrapper will use the NuGet package version as the minimum version.

        static void Initialize()
        {
            const UINT32 c_majorMinorVersion{ WINDOWSAPPSDK_RELEASE_MAJORMINOR };
            PCWSTR c_versionTag{ WINDOWSAPPSDK_RELEASE_VERSION_TAG_W };
            const PACKAGE_VERSION c_minVersion{ WINDOWSAPPSDK_RUNTIME_VERSION_UINT64 };
            const auto c_options{ Options() };
            const HRESULT hr{ ::MddBootstrapInitialize2(c_majorMinorVersion, c_versionTag, c_minVersion, c_options) };
            if (FAILED(hr))
            {
                exit(hr);
            }
        }

        [global::System.Runtime.CompilerServices.ModuleInitializer]
        internal static void AccessWindowsAppSDK()
        {
            uint majorMinorVersion = global::Microsoft.WindowsAppSDK.Release.MajorMinor;
            string versionTag = global::Microsoft.WindowsAppSDK.Release.VersionTag;
            var minVersion = new PackageVersion(global::Microsoft.WindowsAppSDK.Runtime.Version.UInt64);
            var options = Options;
            int hr = 0;
            if (!global::Microsoft.Windows.ApplicationModel.DynamicDependency.Bootstrap.TryInitialize(majorMinorVersion, versionTag, minVersion, options, out hr))
            {
                global::System.Environment.Exit(hr);
            }
        }

For packaged applications, this will set the minimum version in the PackageDependency.

  <Dependencies>
    <TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.19041.0" MaxVersionTested="10.0.19041.0" />
    <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.19041.0" MaxVersionTested="10.0.19041.0" />
    <PackageDependency Name="Microsoft.VCLibs.140.00.Debug.UWPDesktop" MinVersion="14.0.33728.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
    <PackageDependency Name="Microsoft.WindowsAppRuntime.1.5" MinVersion="5001.159.55.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
  </Dependencies>

If you really need to dynamically query the Windows App SDK version after all of this, then as far as I know, the only option is to check your application's dependent packages. The annoyance with this is that this is awkward if your application is unpackaged. Windows.ApplicationModel.Package.Current will fail, so you can't get access to the dependencies that way. I believe that GetCurrentPackageInfo, maybe GetCurrentPackageInfo2 from the Windows API is the only way to do this. You must also be sure to specify the PACKAGE_FILTER_DYNAMIC flag. This will also not get a nice 1.5.4 or anything like this, it will get a version in the form of the MinVersion. Of course, if there is a neater way to check this in C#, then I hope you find it.

[TommiGustafsson-HMP]

The reason is for debugging purposes, we would like to show the version of various packages, so that we are aware what has gone into different builds.

[DarranRowe]

Then basically the Windows App SDK package version is the way to go.
The NuGet package contains a WindowsAppSDK-VersionInfo.h and WindowsAppSDK-VersionInfo.cs file. You are able to use these to know what version of the Windows App SDK you built against.
As stated, the package graph for the process will give you the version actually loaded. The issue is, the "patch version" or the 4 in 1.5.4 isn't currently encoded in the package version number. To show this, consider the package version number for 1.5.4, as taken from WindowsAppSDK-VersionInfo.h

#define WINDOWSAPPSDK_RUNTIME_VERSION_MAJOR             5001u
#define WINDOWSAPPSDK_RUNTIME_VERSION_MINOR             159u
#define WINDOWSAPPSDK_RUNTIME_VERSION_BUILD             55u
#define WINDOWSAPPSDK_RUNTIME_VERSION_REVISION          0u

From what I have seen, originally, the major version of 1 was implied. You could then get the minor version from the package major version / 1000, and you could get the patch version from the package major version % 1000. However, all of the 1.5 releases has 5001 as the package major version.
If you do go through Windows.ApplicationModel.Package or GetCurrentPackageInfo(2), then the version that you obtain matches this versioning scheme, so you can match it to an exact version.

If there is a future release of a versioning API, then that will supercede this answer, but right now, this is the only way I know how to do this.

[stevenbrix]

Version checking is sometimes necessary and desired. For example, we want to add telemetry to our crash analytics for which version of the Windows App Runtime is being used. Since we're a packaged app if we're specifying a 1.5.2 dependency we can be auto-updated to 1.5.4. This happened to us and 1.5.4 introduced a slew of new crashes

[DrusTheAxe]

If you're using WinAppSDK as a framework package you can determine the exact version in use at runtime by snooping thru the package graph

1. Swipe AppModel::PackageGraph::GetCurrentPackageGraph() from https://github.com/microsoft/WindowsAppSDK/blob/main/dev/Common/AppModel.Package.h
2. Call it to retrieve the framework packages in the package graph
3. Walk the returned array of PACKAGE_INFO containing framework packages in the package graph looking for WinAppSDK's framework package:

#include <windows.h>
#include <appmodel.h>
#include <stdio.h>
#include <wil/resource.h>
#include <WindowsAppRuntime-VersionInfo.h>

void FindWinAppSDK()
{
    const UINT32 flags{ PACKAGE_FILTER_DIRECT | PACKAGE_FILTER_STATIC | PACKAGE_FILTER_DYNAMIC | PACKAGE_INFORMATION_BASIC };
    uint32_t packageInfosCount{};
    const PACKAGE_INFO* packageInfos{};
    wil::unique_cotaskmem_ptr<BYTE[]> buffer;
    THROW_IF_IF_FAILED(::AppModel::PackageGraph::GetCurrentPackageGraph(flags, packageInfosCount, packageInfos, buffer));
    const auto packageFamilyName{ ::Microsoft::WindowsAppSDK::Runtime::Packages::Framework::PackageFamilyName };
    for (uint32_t index=0; index < packageInfosCount; ++index)
    {
        const auto& packageInfo{ packageInfos[index] };
        if (CompareStringOrdinal(packageInfo.packageFamilyName, -1, packageFamilyName, -1, TRUE) == CSTR_EQUAL)
        {
            // Found the Windows App SDK framework package in the package graph
            wprintf(L"PackageFullName: %s\n"
                    L"Version.UInt64 : 0x%016X\n",
                    packageInfo.packageFullName, packageInfo.packageId.version.Version);
            return;
        }
    }
}

You don't technically need AppModel::PackageGraph::GetCurrentPackageGraph() just do what it does. But it conveniently wraps up calling the lower level GetCurrentPackageInfo() and it's late on a Sunday evening so optimizations are left as an exercise for the reader :-)