Can't debug packaging project for unpackaged WinUI 3 app (DEP0800)

[Fritierkelle]

Hi,
I added a packaging project to my WinUI3 unpackaged app and set it as startup project (VS 2022/ Windows 11).
I can't debug and get this error (same error when I try to install the MsixBundle):

Creating a new clean layout...
Copying files: Total 12 mb to layout...
Checking whether required frameworks are installed...
Framework: Microsoft.WindowsAppRuntime.1.2/X64, app package version 5001.58.448.0 is not currently installed.
Installing missing frameworks...
Registering the application to run from layout...

DEP0700: Registration of the app failed. [0x80073CF3] Windows cannot install package f7acecac-ea75-4558-b8d3-4d262895a266_1.0.5.0_x64__a1j3z9m6cv6fy
because this package depends on a framework that could not be found. Provide the framework "Microsoft.WindowsAppRuntime.1.2" published by
"CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US", with neutral or x64 processor architecture and minimum version
5001.58.448.0, along with this package to install.
========== Deploy: 1 succeeded, 0 failed, 0 skipped ==========
========== Deploy completed at 3:10 AM and took 03.355 seconds ==========

I also had another error:

DEP0800: The required framework "C:\Users\xxx\source\repos\cpp\UI_Test 3\packages\Microsoft.WindowsAppSDK.1.2.230118.102\build..\tools\MSIX\win10-x64\Microsoft.WindowsAppRuntime.1.2.msix" failed to install. [0x80073D06] Windows cannot install package Microsoft.WindowsAppRuntime.1.2_2000.747.1945.0_x64__8wekyb3d8bbwe because it has version 2000.747.1945.0. A higher version 2000.802.31.0 of this package is already installed.

I had all packages mentioned in the errors installed and uninstalled but the errors run in circle.

These are my appxpackages:

(get-appxpackage microwinappruntime*).packagefullname
Microsoft.WindowsAppRuntime.1.5_5001.58.448.0_x64__8wekyb3d8bbwe
Microsoft.WindowsAppRuntime.1.5_5001.58.448.0_x86__8wekyb3d8bbwe
MicrosoftCorporationII.WinAppRuntime.Main.1.5_5001.58.448.0_x64__8wekyb3d8bbwe
Microsoft.WinAppRuntime.DDLM.5001.58.448.0-x6_5001.58.448.0_x64__8wekyb3d8bbwe
Microsoft.WinAppRuntime.DDLM.5001.58.448.0-x8_5001.58.448.0_x86__8wekyb3d8bbwe
MicrosoftCorporationII.WinAppRuntime.Singleton_5001.58.448.0_x64__8wekyb3d8bbwe
Microsoft.WindowsAppRuntime.1.1_1005.616.1651.0_x64__8wekyb3d8bbwe
Microsoft.WindowsAppRuntime.1.1_1005.616.1651.0_x86__8wekyb3d8bbwe
Microsoft.WindowsAppRuntime.1.3_3000.934.1904.0_x64__8wekyb3d8bbwe
Microsoft.WindowsAppRuntime.1.3_3000.934.1904.0_x86__8wekyb3d8bbwe
Microsoft.WindowsAppRuntime.1.4_4000.1136.2333.0_x86__8wekyb3d8bbwe
Microsoft.WindowsAppRuntime.1.4_4000.1136.2333.0_x64__8wekyb3d8bbwe
Microsoft.WindowsAppRuntime.1.2_2000.802.31.0_x86__8wekyb3d8bbwe

• WinUI 3 Nuget updated to 1.5
• 1.1 (Microsoft Family currently depends on the framework...)
• 1.3 (Microsoft.ScreenSketch currently...)
• 1.4 (Microsoft.YourPhone currently...)

Is it a bug?
(The app runs flawlessly without a packaging project.)

[DarranRowe]

Have you updated the NuGet packages for the packaging project?
When you have a packaging project, it obtains the package dependencies from the NuGet packaged referenced to the packaging project. So, as an example:

You can see from this, the packaging project references 1.5. You really want to keep this in line with the application itself otherwise problems will occur.

If you read the error message that you posted, it is telling you that the packaging project is trying to install 1.2 but there is a different version of 1.2 installed. With the way the Windows App SDK is versioned, the packaging project must be set to 1.5 if the application uses the Windows App SDK 1.5.

[Fritierkelle]

• I cleaned the components by Windows 11 > settings > apps.
• Reinstalled the runtimes and VS asked for 1.2_2000.747.1945.0.
• This time I installed it by the Redistributable .zip file, version number is in the MSIX.inventory file (installed 3 of 4 files [not only the WindowsAppRuntimeInstall.exe] except the singleton because it said that a higher version was already installed.)

I tested in my old app, created also a new app with a WAP project.
The runtime errors are gone but I get the new message:

The target process exited without raising a CoreCLR started event. Ensure that the target process is configured to use .NET Core. This may be expected if the target process did not run on .NET Core.
The program '[16940] CPP_Unpackaged_WAP_TestProject.exe' has exited with code 2147942450 (0x80070032).

I already checked that I have all needed components installed. Any idea?
(The documentation says nothing about .NET core for WAP or winrt/c++)

Do I have to change something here?

[DarranRowe]

Yes, if your application is a C++ application then you really want both of the entries under Debugger type to be Native Only.

That is, unless you are hosting the .NET.

[Fritierkelle]

I am somehow a bit lost.

I have tried all combinations. You really can't find any information about it on the net.
I followed the instructions and double checked the components.
https://learn.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-packaging-dot-net

Sorry,
But is it even possible to package an unpackaged WinUI3 c++ app, has it been done successfully?

[DarranRowe]

Yes it has. Given the debugger output in your last screenshot, I would guess you have WindowsPackageType set to None in the .vcxproj file. This causes the project to compile in a source file that automatically call MddBootstrapInitialize2. You can see what the call itself defaults to by inspecting the MddBootstrapAutoInitializer.cpp file which is part of the Windows App SDK NuGet package. But it defaults to specifying the current version as the version of the SDK to bootstrap with no options.
Since MddBootstrapInitialize2 is only used by unpackaged applications to reference the Windows App Runtime, by default it just errors out. There are two ways of dealing with this. First is just not using WindowsPackageType in the .vcxproj file. This means that you would have to directly call MddBootstrapInitialize2 when needed. But there is a better way. The second option is using the fact that MddBootstrapInitialize2 has some options. One of them is to tell MddBootstrapInitialize2 to do nothing if the application is packaged. The way to enable these options, and in general how the bootstrapper works, is documented.

  <PropertyGroup Label="Globals">
    <CppWinRTOptimized>true</CppWinRTOptimized>
    <CppWinRTRootNamespaceAutoMerge>true</CppWinRTRootNamespaceAutoMerge>
    <MinimalCoreWin>true</MinimalCoreWin>
    <ProjectGuid>{772fb297-9de2-42e1-80c3-021526001dac}</ProjectGuid>
    <ProjectName>TestWinUI3</ProjectName>
    <RootNamespace>TestWinUI3</RootNamespace>
    <!--
      $(TargetName) should be same as $(RootNamespace) so that the produced binaries (.exe/.pri/etc.)
      have a name that matches the .winmd
    -->
    <TargetName>$(RootNamespace)</TargetName>
    <DefaultLanguage>en-US</DefaultLanguage>
    <MinimumVisualStudioVersion>16.0</MinimumVisualStudioVersion>
    <AppContainerApplication>false</AppContainerApplication>
    <AppxPackage>false</AppxPackage>
    <ApplicationType>Windows Store</ApplicationType>
    <ApplicationTypeRevision>10.0</ApplicationTypeRevision>
    <WindowsTargetPlatformVersion>10.0</WindowsTargetPlatformVersion>
    <WindowsTargetPlatformMinVersion>10.0.17763.0</WindowsTargetPlatformMinVersion>
    <UseWinUI>true</UseWinUI>
    <!-- Used to enable automatic bootstrapping of the Windows App SDK, will fail if the application is packaged. -->
    <WindowsPackageType>None</WindowsPackageType>
    <!-- Does the equivalend of calling MddBootstrapInitialize2 with MddBootstrapInitializeOptions_OnPackageIdentity_NOOP. -->
    <!-- This allows this executable to serve as the binary for both a packaged and unpackaged application, without directly callind MddBootstrapInitialize2. -->
    <WindowsAppSDKBootstrapAutoInitializeOptions_OnPackageIdentity_NoOp>true</WindowsAppSDKBootstrapAutoInitializeOptions_OnPackageIdentity_NoOp>
  </PropertyGroup>

The above is a snippet of a test .vcxproj file with this option set.

You should see in Solution Explorer that the package is set as the startup project. The exact same project works without changes if you just set the project itself as the startup project.

It does work, but it is a bit fiddly getting some of the pieces put together. Here is a small example with only minor edits.

TestWinUI3.zip

[Fritierkelle]

Oh ok,
Thank you.
(Yes, that makes sense.)

PS: It all seems extremely time-consuming somehow. How about simply using a switch (packaged/unpackaged/ framework-dependent/ self-contained)? :)

[minfrin]

I think I am suffering the same problem, but not sure (much unix experience, not much windows).

PS C:\Users\minfrin\source\redwax-signtext\src\windows\Redwax SignText Packaging\AppPackages> Add-AppPackage -Path ".\Redwax SignText_1.0.0.0_Win32_Debug_Test\Redwax SignText_1.0.0.0_Win32_Debug.msix" -AllowUnsigned
Add-AppPackage : Deployment failed with HRESULT: 0x80073CF3, Package failed updates, dependency or conflict validation.
Windows cannot install package c78bf4e4-e4e5-44f1-97dd-69e0f4a169db_1.0.0.0_x86__enwe9x4v0qrtw because this package
depends on a framework that could not be found. Provide the framework "Microsoft.WindowsAppRuntime.1.3" published by
"CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US", with neutral or x86 processor
architecture and minimum version 3000.882.2207.0, along with this package to install.
NOTE: For additional information, look for [ActivityId] 2efe139a-721b-0001-2963-0b2f1b72da01 in the Event Log or use
the command line Get-AppPackageLog -ActivityID 2efe139a-721b-0001-2963-0b2f1b72da01
At line:1 char:1
+ Add-AppPackage -Path ".\Redwax SignText_1.0.0.0_Win32_Debug_Test\Redw ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : WriteError: (C:\Users\minfri...in32_Debug.msix:String) [Add-AppxPackage], IOException
    + FullyQualifiedErrorId : DeploymentError,Microsoft.Windows.Appx.PackageManager.Commands.AddAppxPackageCommand

When trying to install the MSIX for testing, I get the same failure: "package depends on a framework that could not be found". How did the MSIX build successfully without error when the dependency was missing?

I understand that the MSIX is self contained, but maybe it's not? What stops end users being sent into dependency hell just installing a package? What I thought I understood and the behaviour before me don't match and I am lost.

In my case, the properties look like this:

  <PropertyGroup Label="Globals">
    <CppWinRTOptimized>true</CppWinRTOptimized>
    <CppWinRTRootNamespaceAutoMerge>true</CppWinRTRootNamespaceAutoMerge>
    <MinimalCoreWin>true</MinimalCoreWin>
    <ProjectGuid>{2779dda1-3214-4c35-84d2-454f2e542cc0}</ProjectGuid>
    <ProjectName>Redwax SignText</ProjectName>
    <RootNamespace>Redwax_SignText</RootNamespace>
    <!--
      $(TargetName) should be same as $(RootNamespace) so that the produced binaries (.exe/.pri/etc.)
      have a name that matches the .winmd
    -->
    <TargetName>$(RootNamespace)</TargetName>
    <DefaultLanguage>en-US</DefaultLanguage>
    <MinimumVisualStudioVersion>16.0</MinimumVisualStudioVersion>
    <AppContainerApplication>false</AppContainerApplication>
    <AppxPackage>true</AppxPackage>
    <ApplicationType>Windows Store</ApplicationType>
    <ApplicationTypeRevision>10.0</ApplicationTypeRevision>
    <WindowsTargetPlatformVersion>10.0</WindowsTargetPlatformVersion>
    <WindowsTargetPlatformMinVersion>10.0.17763.0</WindowsTargetPlatformMinVersion>
    <UseWinUI>true</UseWinUI>
    <EnableMsixTooling>true</EnableMsixTooling>
  </PropertyGroup>

[DarranRowe]

This is more of the case that when you install the package through the command line like this, Windows will not automatically grab the dependencies from the store.
You need to provide the dependencies alongside the package by using the -DependencyPath command line option of Add-AppxPackage. The Windows App SDK packages can be found in the NuGet package itself. For a C++ project, the extracted NuGet package can be found in the packages directory which should be in the same directory as your .sln file.

The packages can be found under the Windows App SDK directory in the tools\MSIX\win10-$(Platform) directory.

The package you need to provide would be Microsoft.WindowsAppRuntime.1.3.msix. I showed an example using 1.5, but the directory layout is the same. You can install DDLM if you wish, and this will match your application's platform. But if you want to install the singleton and main packages, try to match the system's platform.

If you need to provide the VC Redistributable, you can find that under Program Files (x86) on your development machine. Remember, since you are trying to install a debug package, the VC Runtime isn't redistributable. This will only install alongside Visual C++ or the Windows SDK. The release version is redistributable and you should be able to find versions of it available to download from Microsoft.

To deploy this via command line, you would then really do the following.

1. Verify what you need. The generated AppxManifest.xml will contain all of this information.

  <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.WindowsAppRuntime.1.5" MinVersion="5001.58.448.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
    <PackageDependency Name="Microsoft.VCLibs.140.00.Debug.UWPDesktop" MinVersion="14.0.30704.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
    <PackageDependency Name="Microsoft.VCLibs.140.00.Debug" MinVersion="14.0.30704.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
  </Dependencies>

This is from a test project. From this, you can see that it declares a dependency on Microsoft.WindowsAppRuntime.1.5, Microsoft.VCLibs.140.00.Debug.UWPDesktop and Microsoft.VCLibs.140.00.Debug. I will use the x86/debug version to match your situation.

2. Figure out where all of the dependencies are. I'm going to gather everything into a single directory for ease of deployment, but you don't have to.

These, along with the application package are then copied alongside the application package.

The directory where everything is stored doesn't matter here. I just already had this directory set up for network installs.

3. Install the package along with the dependencies.

If this doesn't work for you then please comment back.

[Fritierkelle]

So I gave up on it for now and wanted to tackle it again in a month, it's really extremely time-consuming.

Don't know if this helps, but I've had problems all along because there was always a dependency on 1.2, even though I usually upgrade to a stable version.

I'm really not the senior specialist. When I cleaned the packages and components, 1.2 kept coming back.
I found a post on StackOverFlow and removed the following line from my vcxproj, now the old version is finally gone from the packages folder.

<Error Condition="!Exists('..\packages\Microsoft.WindowsAppSDK.1.2.230118.102\build\native\Microsoft.WindowsAppSDK.targets')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\Microsoft.WindowsAppSDK.1.2.230118.102\build\native\Microsoft.WindowsAppSDK.targets'))" />

Regards