Help, can't install Windows App SDK,

[cdytoby]

Installing license: WAR_MAINPACKAGE_LICENSE
Install result : 0x0
Deploying package: Microsoft.WindowsAppRuntime.1.0_0.319.455.0_x64__8wekyb3d8bbwe
Package deployment result : 0x80073cfb One or more install operations failed. Result: 0x80073cfb

I checked my installed things with winget, and nothing in the list indicates "Microsoft.WindowsAppRuntime"

I'm using Windows 10 21H1, Visual Studio 2022 is also installed. Windows App SDK vsix thing is also installed.

[DrusTheAxe]

0x80073cfb = ERROR_PACKAGE_ALREADY_EXISTS
The provided package is already installed, and reinstallation of the package was blocked. Check the AppXDeployment-Server event log for details.

This should be handled which implies it's not that straightforward.

Please run the following command and share the result:

powershell -c get-appxpackage microsoft.win*app*run*

@sachintaMSFT for follow up

[cdytoby]

Thanks for the answer, after using powershell and the commands related to appxpackage, I found where the problem is, but I'm not sure why it's causing it, I'll explain here.

• The package Microsoft.WindowsAppRuntime was indeed installed previously, I'm sure I didn't do that.
• Based on installation date, this package seems to be installed together with WinUI 3 Controls Gallery from MS Store.
• Deleting WinUI 3 Controls Gallery from windows setting didn't uninstall Microsoft.WindowsAppRuntime.
• So I have to use Remove-AppxPackage command to delete it manually for x64, x86 and arm
• Then I can finally install Microsoft.WindowsAppRuntime from official tutorial site.

Also, there is another thing, after doing this, the other help post I created, #1935
is solved after doing these steps.

So that means, whatever "WindowsAppRuntime" deployed automatically to my computer, is NOT THE SAME as the package manually installed, and I can confirm they share the same version 1.0_0.319.455. But I can't confirm if they have the same hash.

So you may want to investigate that.

@sachintaMSFT

[DrusTheAxe]

• The package Microsoft.WindowsAppRuntime was indeed installed previously
  I can confirm they share the same version 1.0_0.319.455

Was it the same exact package? e.g. same package full name?

Deleting WinUI 3 Controls Gallery from windows setting didn't uninstall Microsoft.WindowsAppRuntime.

Nor would it, as W3CG was installed from MS Store. See below.

Also, there is another thing, after doing this, the other help post I created, #1935 is solved after doing these steps.

Makes sense. I suspect the Boootstrap.Net API failed because it loaded the Bootstrap DLL but couldn't find a framework package to satisfy the dynamic dependency. Either you didn't have the framework package previously installed, or you did but wrong architecture, or you did but version didn't satisfy the bootstrap API's minVersion parameter. Hard to say without more detailed logs and machine state information. But I'm glad to hear, whatever the reason was, it's no longer a problem for you.

But I can't confirm if they have the same hash

What hash? As in, the package's content?

That shouldn't matter. MSIX assumes package identity means something, and thus 2 packages with the same identity are assumed to have identical bits. If you change bits but don't change identity...bad things happen. At best you can't install because Windows already thinks it's installed. Other weird behavior can crop up e.g. you're built with and expect Foo but actually running with Foo(variant2) and what hapens very much depends on the exact differences and code paths involved.

I've seen a handful of cases over the years where devs changed content and didn't update identity, and they were surprised to see problems. We had a couple of fire drills waaay back in Win8x days that taught a lot of folks "don't do that". It might even be fair to say the experiences left deep emotional scars... ;-)

So we're very careful around this. In fact our build/release processes make it hard to do this even if you intentionally tried to. If you can repro this, or otherwise find any evidence of two WinAppSDK packages with the same identity but different bits we would be very interested to hear more.

Based on installation date, this package seems to be installed together with WinUI 3 Controls Gallery from MS Store.

As I'd expect. WinUI 3 Controls Gallery declares a <PackageDependency> and, when distributed via MS Store, the MS Store install processes downloads and installs dependencies. Thus if you install W3CG from MS Store your machine will have the WinAppSDK framework package as well as the W3CG package.

Even if you remove the W3CG package it won't remove MS Store deployed framework packages. The reason is a bit technical. The TL;DR is because it was explicitly installed. The SuperTLDR is, 'cause, that's how Store does things :P

The more involved answer...

Removing a main package will remove associated dependencies if they're no longer needed. This is a form of garbage collection where removing a main package removes its associated framework packages if (1) there are no more outstanding references to it and (2) it's not 'pinned'. The former means there are no remaining packages registered any user on the machine with a dependency on the framework package, and the package is not preinstalled. The latter means the framework package was not explicitly installed.

Examples as pictures are worth a thousand words...

For some examples let's assume main package Foo declares <PackageDependency Name="Bar"...>. Let's also assume Windows tracks packages on the machine in a database, so on a new machine without Foo or Bar the database is empty.

NOTE: I'll use Powershell cmdlet(ish) syntax but they're just wrappers over the PackageManager API e.g. Add-AppxPackage == pkgmgr.AddPackageAsync(). All MSIX package management ultimately boils down to PackageManager and the deployment stack under it.

Simple example: Foo+Bar

You could explicitly install these packages e.g. starting with our clean machine

Package	IsExplicitlyInstalled	Dependencies

Let's install Foo+Bar in one step:

Add-AppxPackage Foo.msix -DependencyPackages Bar.msix

Package	IsExplicitlyInstalled	Dependencies
Bar	false
Foo	true	Bar

Notice how Bar.IsExplicitlyInstalled=false. That's because we explicitly installed Foo and implicitly installed Bar. This operation told Windows "Install Foo, oh and if you need Bar you can find it here." Windows needs to satisfy dependencies to successfully install. That dependency resolution uses packages specified and those already on the machine.

Remove-AppxPackage will deregister a package and, if no longer needed, de-stage it (physically remove it from the machine). If we try to remove Bar

Remove-AppxPackage Bar

we fail because Foo depends on it (deregistering Bar would break Foo). But if we remove Foo

Remove-AppxPackage Foo

Package	IsExplicitlyInstalled	Dependencies

Windows removes Foo, then sees no package depends on Bar and it's not explicitly installed (i.e. not 'pinned', in GC-speak) and thus Bar is no not needed and removes it.

Simple example: Bar then Foo

So that's all well and good but what's it got to do with MS Store? Simple: Store doesn't implicitly install dependencies.

Instead of one command with implicit dependencies you can use multiple individual commands to explicitly install each package e.g. going back to our clean machine

Package	IsExplicitlyInstalled	Dependencies

Let's install Bar then install Foo:

Add-AppxPackage Bar.msix

Package	IsExplicitlyInstalled	Dependencies
Bar	true

Add-AppxPackage Foo.msix

Package	IsExplicitlyInstalled	Dependencies
Bar	true
Foo	true	Bar

Notice how Bar.IsExplicitlyInstalled=true. That's because it was. So now let's remove Foo

Remove-AppxPackage Foo

Package	IsExplicitlyInstalled	Dependencies
Bar	true

We're back to where we were before installing Foo. Bar remains staged and registered because it was explicitly installed. Now if we

Remove-AppxPackage Bar

Package	IsExplicitlyInstalled	Dependencies

Poof! All gone.

But what if you try to remove Bar before Foo?

Package	IsExplicitlyInstalled	Dependencies
Bar	true
Foo	true	Bar

Remove-AppxPackage Bar

Package	IsExplicitlyInstalled	Dependencies
Bar	false
Foo	true	Bar

Bar is still present. It can't be removed because packages depend on it. But the Remove command did clear Bar.IsExplicitlyInstalled (now false). So now if we

Remove-AppxPackage Foo

Package	IsExplicitlyInstalled	Dependencies

Windows removed Foo, then saw Bar wasn't referenced (no dependents) AND isn't pinned (Bar.IsExplicitlyInstalled=false) and thus no longer needed and removed it.

There's more complicating factors - provisioning, Win11's built-in Dynamic Dependencies, Stage then Register operations instead of Add, etc. MSIX deployment has a lot of features and behavior, but this explains the core of the matter.

And that's why...

MS Store explicitly installs framework packages, then main packages. That's why simply removing a main package won't remove associated frameworks the Store installed, even if they're not otherwise referenced.

For non-Store installs YMMV. All depends on how PackageManager was called

[cdytoby]

Makes sense. I suspect the Boootstrap.Net API failed because it loaded the Bootstrap DLL but couldn't find a framework package to satisfy the dynamic dependency. Either you didn't have the framework package previously installed, or you did but wrong architecture, or you did but version didn't satisfy the bootstrap API's minVersion parameter. Hard to say without more detailed logs and machine state information. But I'm glad to hear, whatever the reason was, it's no longer a problem for you.

• What do you mean "framework package"?
• I don't have any detailed log, because that was the only exception log I can get.
• I don't have the interest to try to reproduce this issue for now, sorry about that.

What hash? As in, the package's content?

I mean the thing after "x64__", "__8wekyb3d8bbwe". I assume it's some kind of hash, but if it's not then I'll call it "full name" from now on.

So we're very careful around this. In fact our build/release processes make it hard to do this even if you intentionally tried to. If you can repro this, or otherwise find any evidence of two WinAppSDK packages with the same identity but different bits we would be very interested to hear more.

Good to know, I can't verify if the full name is the same one, but in my memory it should be the same one (start from 8 and has "8bb" in the string).

Anyway the point is, the one previously installed can't run WinUI3, and I have to uninstall them manually and install a "different package" manually to get WinUI3 working.

[cdytoby]

I have one more question: why can't I install Windows App SDK from Visual Studio directly? Why should I install it from extra source?

[ghost]

10,000 upvotes for this question. I just posted an issue on the docs page. Why does this have to be so half-baked and confusing?

Confusion about VSIX installation

[DrusTheAxe]

What do you mean "framework package"?

MSIX supports different types of package: Main, Framework, Optional, Resource, Bundle. Oversimplistically put, Main is to Framework as Exe is to DLL, or Process is to Thread. The key differences: Main packages can declare <Application>s (Fwks can't), can declare <Capability>s (Fwks can't) and there's secondary impacts e.g. Packaged COM today can only be declared as child elements of an <Application> so can't be declared in framework packages.

To round things out, Optional packages are akin to taking a Main package and slicing it into a required (Main) and optional packages, then you can install the required (Main) package and 0+ Optional. At runtime the Optional packages run in the context of the Main package. For conceptual uses think of DLCs for games, or the Adobe or Office suite where e.g. you install Office and have Word, Excel and Powerpoint installed but not Visio.

Resource packages are meant for localization resources.

Bundles are very different beasts. They provide a convenient way to pack multiple related packages into a package for easier distribution.

You may also find mention of 'XAP'. That's an old concept from Windows Mobile and was never supported elsewhere.

Windows App SDK is deployed via multiple MSIX packages. TL;DR WinAppSDK's is installed via framework and main packages. It's not just a framework package. This is significant for below.

What hash? As in, the package's content?
I mean the thing after "x64__", "__8wekyb3d8bbwe". I assume it's some kind of hash, but if it's not then I'll call it "full name" from now on.

That's the "PublisherId" which, yes, is a hash of "Publisher". As Publisher can be up to 4K long and contain spaces, backslashes and other inconvenient ;-) characters it's rather awkward for common use. PublisherId is a hashed form of Publisher, which we Base-32 encode (using the Crockford variant) resulting in a short string of case-insensitive alphanumerics.

Package identity is a 5-tuple: Name, Version, Architecture, ResourceId, Publisher. This can be expressed as a struct (PACKAGE_ID), WinRT object (PackageId), or other syntax. Package Full Name is a convenient stringified syntax for package identity (name_version_architecture_resourceid_publisherId).

P.S. Package Family is a 2-tuple: Name, Publisher. Again, multiple ways to express it though the string form of PackageFamilyName (name_publisherid) is the most common one.

I have to uninstall them manually and install a "different package" manually to get WinUI3 working.

That shouldn't happen so I suspect something isn't quite what it seemed. But it's unclear why w/o more data and it's a bit late to collect that now to explore further. If you see this again (or similar issues) please use FeedbackHub to collect data for further analysis. Most importantly, when defining a FeedbackHub issue make sure Category is Developer Platform / App Deployment

That collects data especially useful for MSIX troubleshooting (certain logs, machine state like packages installed, etc).

I have one more question: why can't I install Windows App SDK from Visual Studio directly?

TL;DR you can, but unfortunately not efficiently today. You can do it inefficiently, if you're willing to negatively impact common developer experiences (e.g. build). We'd prefer not to. Primum non nocere ("first, do no harm").

The more involved explanation...

That question has 2 answers given the 2 scenarios (packaged+unpackaged), each with 2 sub-scenarios (product+devtime).

If you're an unpackaged app then your product install needs to also install WinAppSDK's runtime. You can install the appropriate MSIX packages and licenses, or as a convenience run WindowsAppRuntimeInstall.exe which does the work for you.

At devtime, assuming you use VS, VS has no support to install the MSIX packages when you hit F5 (or any other action). This is something we'd like to address but doing so (well) is difficult. In VS there are multiple pathways to launch an app (just look at Run vs Debug, which themselves aren't just 2 code paths) and VS currently lacks the necessary hooks to reliably add install if-necessary logic. Well, that's not entirely true. It's possible -- if you do so as a post-build event. Meaning every time you build. That 'tax' always doing so (no matter how much or little you build) is unappealing. It's in our backlog but not something we could bake out for 1.0. If this interests you please share your feedback to help us identity features of interest to the community and where to prioritize our efforts (after all there's only so many days in an hour 😉)

If you're a packaged app and MS Store distributed then Store can automagically download and install your framework package dependencies if/when needed, but there's currently no support to install other 'related' main packages -- because it doesn't know there's a dependency. Store knows you depend on a framework package because your Main package's appxmanifest.xml declares <PackageDependency> but that can only target framework packages. There's currently no way to declare a dependency on another main package :-( thus Store doesn't know you depend on another main package (e.g. Microsoft.WindowsAppRuntime.Main.1.0). Packaged apps use the Deployment API to workaround this limitation. We're investigating ways to remove this limitation but not something we could bake out for 1.0. Again, if this interests you please share your feedback.

At devtime, VS has support to install framework dependencies but not 'related' main packages. This is why using VS to develop a packaged app may install parts of WinAppRuntime but an incomplete subset. The Deployment API addresses this for devtime equally well as for runtime.

Alternatively, if you're a packaged app but not Store distributed (or simply have no network connection) you can directly install WinAppSDK's runtime just like unpackaged apps do.

[cdytoby]

@DrusTheAxe
Thanks, it's a little bit too long to read, but I want to ask one more thing about winui3 and/or windows runtime sdk:

If I want to deply my app (with WinUI3, target latest windows 10 and 11) in a portable way (just exe with a bunch of files packed into zip), without using any Microsoft Store or UWP thing, does that mean I need "Unpackaged" way? Does target machine running this app also require installing Windows App SDK or not?

[riverar]

@cdytoby Your app will need to ship/install the Windows App Runtime. See also https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/deploy-unpackaged-apps

[rcohn]

Hi @DrusTheAxe and @riverar -

I think I was having the same problem with running an unpackaged WinUI3 app. I built the app on one Win10 system and it runs fine (from a non-admin cmd prompt or File Explorer). But when executing that same app bundle on my other Win10 system, it exceptions. When building from VS2022, I do see an exception message that appears to be related to this long thread:

Exception thrown: 'System.Runtime.InteropServices.COMException' in Microsoft.WindowsAppRuntime.Bootstrap.Net.dll

I performed the above powershell command powershell -c get-appxpackage microsoft.win*app*run* on both systems and it came back empty.

I think, perhaps, that the difference between the two systems was that on the first system where the app executes, I figured out from the above comment that I needed to install the Windows App Runtime, Microsoft.WindowsAppRuntime.Redist.1.0.0, on the second system.

So my question is whether it will be a permanent need to install this runtime on any target systems in order to be able to run the app?

Thanks very much.

[DrusTheAxe]

need to install this runtime on any target systems in order to be able to run the app?

If you're an unpackaged app you need the runtime installed. More information available here

The 1.1 roadmap notes the upcoming option to use Self-contained deployment. You may find this of interest.

[ajkennedy-HEC]

I'd like to point out that this exact situation just bit me while I was trying to follow the ms docs for a new WinUI3 app. It threw an exception on the first run of an unpackaged app.

Exception thrown: 'System.Runtime.InteropServices.COMException' in Microsoft.WindowsAppRuntime.Bootstrap.Net.dll

I also had the WinUI 3 Controls Gallery installed from the Windows Store. The ps command mentioned above netted me two installed packages:

PS C:\> get-appxpackage microsoft.win*app*run*


Name              : Microsoft.WindowsAppRuntime.1.0
Publisher         : CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Architecture      : X64
ResourceId        :
Version           : 0.319.455.0
PackageFullName   : Microsoft.WindowsAppRuntime.1.0_0.319.455.0_x64__8wekyb3d8bbwe
InstallLocation   : C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.0_0.319.455.0_x64__8wekyb3d8bbwe
IsFramework       : True
PackageFamilyName : Microsoft.WindowsAppRuntime.1.0_8wekyb3d8bbwe
PublisherId       : 8wekyb3d8bbwe
IsResourcePackage : False
IsBundle          : False
IsDevelopmentMode : False
NonRemovable      : False
IsPartiallyStaged : False
SignatureKind     : Store
Status            : Ok

Name              : Microsoft.WindowsAppRuntime.1.0
Publisher         : CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Architecture      : X86
ResourceId        :
Version           : 0.319.455.0
PackageFullName   : Microsoft.WindowsAppRuntime.1.0_0.319.455.0_x86__8wekyb3d8bbwe
InstallLocation   : C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.0_0.319.455.0_x86__8wekyb3d8bbwe
IsFramework       : True
PackageFamilyName : Microsoft.WindowsAppRuntime.1.0_8wekyb3d8bbwe
PublisherId       : 8wekyb3d8bbwe
IsResourcePackage : False
IsBundle          : False
IsDevelopmentMode : False
NonRemovable      : False
IsPartiallyStaged : False
SignatureKind     : Store
Status            : Ok

After some manual uninstalling via remove-appxpackage I cleaned those out, and ran the appropriate WindowsAppRuntimeInstall.exe files (x64/x86) from the official download.

Then, the PS query was far more fruitful:

PS C:\> get-appxpackage microsoft.win*app*run*


Name              : Microsoft.WindowsAppRuntime.1.0
Publisher         : CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Architecture      : X64
ResourceId        :
Version           : 0.319.455.0
PackageFullName   : Microsoft.WindowsAppRuntime.1.0_0.319.455.0_x64__8wekyb3d8bbwe
InstallLocation   : C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.0_0.319.455.0_x64__8wekyb3d8bbwe
IsFramework       : True
PackageFamilyName : Microsoft.WindowsAppRuntime.1.0_8wekyb3d8bbwe
PublisherId       : 8wekyb3d8bbwe
IsResourcePackage : False
IsBundle          : False
IsDevelopmentMode : False
NonRemovable      : False
IsPartiallyStaged : False
SignatureKind     : Store
Status            : Ok

Name              : Microsoft.WindowsAppRuntime.1.0
Publisher         : CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Architecture      : X86
ResourceId        :
Version           : 0.319.455.0
PackageFullName   : Microsoft.WindowsAppRuntime.1.0_0.319.455.0_x86__8wekyb3d8bbwe
InstallLocation   : C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.0_0.319.455.0_x86__8wekyb3d8bbwe
IsFramework       : True
PackageFamilyName : Microsoft.WindowsAppRuntime.1.0_8wekyb3d8bbwe
PublisherId       : 8wekyb3d8bbwe
IsResourcePackage : False
IsBundle          : False
IsDevelopmentMode : False
NonRemovable      : False
IsPartiallyStaged : False
SignatureKind     : Store
Status            : Ok

Name              : Microsoft.WindowsAppRuntime.Singleton
Publisher         : CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Architecture      : X64
ResourceId        :
Version           : 0.319.455.0
PackageFullName   : Microsoft.WindowsAppRuntime.Singleton_0.319.455.0_x64__8wekyb3d8bbwe
InstallLocation   : C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.Singleton_0.319.455.0_x64__8wekyb3d8bbwe
IsFramework       : False
PackageFamilyName : Microsoft.WindowsAppRuntime.Singleton_8wekyb3d8bbwe
PublisherId       : 8wekyb3d8bbwe
IsResourcePackage : False
IsBundle          : False
IsDevelopmentMode : False
NonRemovable      : False
Dependencies      : {Microsoft.WindowsAppRuntime.1.0_0.319.455.0_x64__8wekyb3d8bbwe}
IsPartiallyStaged : False
SignatureKind     : Store
Status            : Ok

Name              : Microsoft.WinAppRuntime.DDLM.0.319.455.0-x6
Publisher         : CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Architecture      : X64
ResourceId        :
Version           : 0.319.455.0
PackageFullName   : Microsoft.WinAppRuntime.DDLM.0.319.455.0-x6_0.319.455.0_x64__8wekyb3d8bbwe
InstallLocation   : C:\Program
                    Files\WindowsApps\Microsoft.WinAppRuntime.DDLM.0.319.455.0-x6_0.319.455.0_x64__8wekyb3d8bbwe
IsFramework       : False
PackageFamilyName : Microsoft.WinAppRuntime.DDLM.0.319.455.0-x6_8wekyb3d8bbwe
PublisherId       : 8wekyb3d8bbwe
IsResourcePackage : False
IsBundle          : False
IsDevelopmentMode : False
NonRemovable      : False
Dependencies      : {Microsoft.WindowsAppRuntime.1.0_0.319.455.0_x64__8wekyb3d8bbwe}
IsPartiallyStaged : False
SignatureKind     : Developer
Status            : Ok

Name              : Microsoft.WinAppRuntime.DDLM.0.319.455.0-x8
Publisher         : CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Architecture      : X86
ResourceId        :
Version           : 0.319.455.0
PackageFullName   : Microsoft.WinAppRuntime.DDLM.0.319.455.0-x8_0.319.455.0_x86__8wekyb3d8bbwe
InstallLocation   : C:\Program
                    Files\WindowsApps\Microsoft.WinAppRuntime.DDLM.0.319.455.0-x8_0.319.455.0_x86__8wekyb3d8bbwe
IsFramework       : False
PackageFamilyName : Microsoft.WinAppRuntime.DDLM.0.319.455.0-x8_8wekyb3d8bbwe
PublisherId       : 8wekyb3d8bbwe
IsResourcePackage : False
IsBundle          : False
IsDevelopmentMode : False
NonRemovable      : False
Dependencies      : {Microsoft.WindowsAppRuntime.1.0_0.319.455.0_x86__8wekyb3d8bbwe}
IsPartiallyStaged : False
SignatureKind     : Developer
Status            : Ok

The two exes installed a total of 5 packages where there were previously two. This completely solved the Visual Studio issue, and I was immediately able to run the sample project without the exception.

Is it possible that the provided installers immediately quit when they see that the Microsoft.WindowsAppRuntime.1.0 is installed, but fail to check for the Microsoft.WindowsAppRuntime.Singleton and Microsoft.WinAppRuntime.DDLM packages?

[cdytoby]

Good job on reproduce this issue, I believe we can create an issue instead of discussing it here.

[float34]

@ajkennedy-HEC Hi, can you please specify what have you uninstalled with remove-appxpackage?

[float34]

Found a solution myself:

1. Uninstall WinUI 3 Controls gallery app
2. Execute in Powershell: get-appxpackage microsoft.win*app*run* | Remove-AppxPackage
3. Install WInAppSDK runtime using the official link

[gaziduc]

Just ran into the same problem, updating Nuget packages in Visual Studio (Microsoft.Windows.SDK.BuildTools and Microsoft.WindowsAppSDK) did the trick for me.