Bootstraping Windows App SDK 1.0 throws exception System.Runtime.InteropServices.COMException: 'There was no match for the specified key in the index. (0x80070491)'

[nikolayvpavlov]

Describe the bug

A clean WinForms project in Net 6.0 that references Windows App SDK 1.0 stable, when started, fails with the following exception:

System.Runtime.InteropServices.COMException: 'There was no match for the specified key in the index. (0x80070491)'

The exception is on line:
Bootstrap.Initialize(0x00010000);

If I run the program from Windows Explorer, it dies quietly. I can see the following in event viewer:

Exception Info: System.Runtime.InteropServices.COMException (0x80070491): There was no match for the specified key in the index. (0x80070491)
   at Microsoft.Windows.ApplicationModel.DynamicDependency.NativeMethods.MddBootstrapInitialize_Throw(UInt32 majorMinorVersion, String versionTag, PackageVersion packageVersion)
   at Microsoft.Windows.ApplicationModel.DynamicDependency.Bootstrap.Initialize(UInt32 majorMinorVersion, String versionTag, PackageVersion minVersion)
   at Microsoft.Windows.ApplicationModel.DynamicDependency.Bootstrap.Initialize(UInt32 majorMinorVersion, String versionTag)
   at Microsoft.Windows.ApplicationModel.DynamicDependency.Bootstrap.Initialize(UInt32 majorMinorVersion)
   at AWindowsForms.Program.Main() in C:\Projects\Windows Desktop 2022\AWindowsForms\Program.cs:line 13

Windows SDK 1.0 redistributable is installed. Trying to re-install it says:

Installing license: WAR_MAINPACKAGE_LICENSE
Install result : 0x0
Deploying package: Microsoft.WindowsAppRuntime.1.0_0.319.455.0_x64__8wekyb3d8bbwe
Package deployment result : 0x80073cfb The provided package is already installed, and reinstallation of the package was blocked. Check the AppXDeployment-Server event log for details.
One or more install operations failed. Result: 0x80073cfb

Steps to reproduce the bug

Create a clean WinForms project in Net 6.0.

In the proj file, add:

    <TargetPlatformMinVersion>10.0.17763.0</TargetPlatformMinVersion>
    <TargetPlatformVersion>10.0.17763.0</TargetPlatformVersion>
    <TargetPlatformIdentifier>Windows</TargetPlatformIdentifier>
    <RuntimeIdentifiers>win10-x86;win10-x64</RuntimeIdentifiers>

to

Then add Microsoft.WindowsAppSdk 1.0.0. NuGet package.

In Program.cs, add the following code:

Bootstrap.Initialize(0x0001_0000);

Run the program.

Expected behavior

The application should start without exceptions

Screenshots

No response

NuGet package version

1.0.0

Packaging type

Unpackaged

Windows version

Windows 11 version 21H2 (22000)

IDE

Visual Studio 2022

Additional context

No response

[nikolayvpavlov]

The problem is with the version of the Windows App SDK 1.0 redistributable. This issue has more details about the problem and how to workaround it. Still, a better solution should be provided.

[DrusTheAxe]

We've identified the root problem and working on a fix.

The problem is due to Store's submission pipeline changing a submitted package's appxmanifest.xml (injecting <mp:PhoneIdentity> and UTF-8 BOM if not present and some textual reformatting of whitespace). This occurs between when we retrieved our signed packages from the Store and they're made available to users via Store distribution. Call it before-Store-offering vs after-Store-offering, or simply before-Store vs after-Store.

For example, if you install the WinUI3 Control Gallery (which declares a dependency on WinAppSDK) the installed WinAppSDK framework package (after-Store) is not bit-identical with the framework package (before-Store) despite having the same identity. This is why if you install the WinAppSDK framework via the Store (after-Store) and then run WindowsAppRuntimeInstaller.exe the latter fails because a package with the same identity but different bits is installed. This violates a base principle of MSIX, that a package identity is a constant across and time. That N packages with the same identity are expected to have the same bits.

The problem occurs if you install the WinAppSDK 1.0.0 framework package from the Store and then install the WinAppSDK 1.0.0 framework package (same identity) from WindowsAppRuntimeInstaller.exe, the NuGet or VSIX.

We're adjusting our processes to produce the identical manifest before we Store-sign WinAppSDK package as after. No more discrepancy and thus no problem. This change is on the short-list for our next servicing update (aka 1.0.1).

NOTE: The servicing update has a different package identity. As the MSIX package version is derived in part by the date/time of the build new MSIX packages won't be version 0.319.455.0 (the version for release 1.0.0).

The workaround for 1.0.0 is to not mix WinAppSDK packages from the Store and non-Store sources. Don't run WindowsAppRuntimeInstall.exe if Store's installed 1.0.0 e.g. if Store's installed the WinUI3 Control Galley or other package dependent on WinAppSDK 1.0.

https://task.ms/38095216

[jeremyVignelles]

@DrusTheAxe Thanks for the explanation, but would you mind explaining what step should we take to workaround the issue, in WinUI noob terms?

i understood that there is a version conflict somewhere, but should I uninstall something from the store? Run a PS command (which one?)

Coming from WPF, I don't really unserstand what's going on with the store, I'm just creating my first blank app and running it in unpackaged mode.

[DrusTheAxe]

@DrusTheAxe Howard Kapustein FTE Thanks for the explanation, but would you mind explaining what step should we take to workaround the issue, in WinUI noob terms?

1. Run powershell -c "get-appxpackage micro*win*appruntime* | remove-appxpackage
   This should remove all WinAppSDK MSIX package registered for the user
2. Run powershell -c $(get-appxpackage micro*win*appruntime*).packagefullname
   If anything shows (if so, probably the framework, Microsoft.WindowsAppRuntime.1.0) then you have some packaged app installed which depends on WinAppSDK. You need to uninstall that/them then repeat step 1 to deregister the remaining WinAppSDK package(s). For example, if you installed the WinUI3 Control Gallery from the Store you need to remove it so the framework package can be removed.
3. Download the redist zip (contains the installer .exe) from here (look for "Download Installer and MSIX packages")
4. Crack open the redist zip and run WindowsAppRuntimeInstaller.exe that matches your machine's cpu e.g. run WindowsAppSDK-Installer-x64\WindowsAppRuntimeInstall.exe on an x64 machine. NOTE: If you see any error about Stage you can ignore it (especially error 5 or 0x80070005), false error (means the packages are installed for you, not provisioned for every other user too).

A package identity is assumed to mean a specific, unique set of bits across space and time. If a package says it's Foo_1.2.3.4_x64__1234567890abc then it's bits are a constant. The problem is WinAppSDK's packages installed by the Store aren't identical to what you get via WinAppSDK's installer, nuget and VSIX.

TL;DR there was a bug in how we cooked the packages, what should have been identical wasn't. We've identified the problem and changing our processes to ensure it doesn't happen again. This should be corrected in the next servicing fix (1.0.1). For now, the workaround if you hit this is to uninstall WinAppSDK's packages then install them e.g. via the installer.

[jeremyVignelles]

Awesome thanks, that procedure definitely worked 👍

[davidknapman-cl]

Is this meant to work now that 1.0.1 has released? I tried updating a small project yesterday but still seem to be hitting the same/similar error.

[DrusTheAxe]

Is this meant to work now that 1.0.1 has released?

Yes. 1.0.1 should have the fix

Did you rebuild with the 1.0.1 nuget? Did you run the 1.0.1 installer?

[DrusTheAxe]

1.0.1 was released with the fix

#2291