Using Windows App SDK in Qt app (without a Visual Studio project)

[triplef]

We’re building our packaged Win32 app using Qt and would like to use the Windows App SDK. Is this a supported scenario or has anyone managed to use the Windows App SDK / WinUI outside of a Visual Studio project? Specifically, we’d like to take advantage of the AppWindow API to make our app window look more native/modern.

I downloaded the Microsoft.WindowsAppSDK Nuget package, but it seems to be missing most of the headers for WinUI or the AppWindow API. I read that these are provided as sub-projects to the Nuget package – is there any way to download these manually?

[BenJKuhn]

We've focused primarily on .NET and msbuild up to this point, but have been collecting feedback related to supporting other build environments in the future. Are you developing in C++ then ? Which build system are you using?

Thanks,

Ben

[triplef]

Thanks for the explanations @DrusTheAxe!

I’m running the latest official Windows 10 release 21H2, so it sounds like the API set should be there. Additionally I can run the Windowing sample project, which also calls GetWindowIdFromWindow(), without issues on my system.

Is there anything else I could be missing that Visual Studio does behind the scenes, or do I need to maybe call cppwinrt with different parameters than the following? I didn’t find much too documentation on it and ran with the first thing that let me build my code...

cppwinrt.exe -in lib\uap10.0.18362 -out include -ref 10.0.22000.0

[DrusTheAxe]

I’m running the latest official Windows 10 release 21H2, so it sounds like the API set should be there.

I didn't say that, just that it's not present on <=21H1. I'm not sure when it first appeared. @ionvasilian would know more

do I need to maybe call cppwinrt with different parameters than the following

That looks OK by me though IANACWE (I Am Not A C++/WinRT Expert). But I don't see how that would matter, this error should occur if GetWindowIdFromWindow is called (for any reason) given the right platform / environmental soup. It's been escalated to the windowing team for further investigation.

If you use VS the C++/WinRT pluigin (vsix?) integrates into VS so you get the usual property UI under project Settings to fiddle with values, build pipeline integration etc. If you need to know more C++/WinRT experts are pretty active on the github project pages

[triplef]

I’ve created a small sample project with Visual Studio 2022 (17.0.4) that reproduces the issue for me:
https://www.dropbox.com/s/16qq0uq28vq35m9/WinUITest.zip?dl=0

Here is how I set up the project:

1. Create a new VS project using the "Windows Desktop Application" template
2. Add Microsoft.WindowsAppSDK NuGet package
3. Generate headers from the WinMD files by running the following inside the Windows App SDK package folder:
   cppwinrt.exe -in lib\uap10.0.18362 -out ..\..\WindowsAppSDK-include-gen -ref 10.0.22000.0
4. Add the folder with the generated headers to the include path and configure project to use C++17.
5. Call MddBootstrapInitialize() in wWinMain(), and add some code to call GetWindowIdFromWindow() in InitInstance()

Please let me know if there’s anything else I can do to help track down this issue.

[DrusTheAxe]

We believe we've identified the root cause¹ and working on a fix. Once verified it'll be considered for 1.0-servicing and very likely to meet the bar.

¹ The logic detecting if a new(ish) function is available potentially got wrong answers due to specific code (some N layers deep) not working as expected ('cause, complex compatibility reasons). An alternative implementation that doesn't hit this problem is being pursued.

Thank you for reporting this, and for your patience and assistance helping us identify the problem.

+@jeffstall @tiberiu2 @ionvasilian for future updates on the fix

[gabbybilka]

Fix is in 1.0.1 servicing: #2291

[triplef]

Solution for unpackaged app

Notwithstanding the issue with GetWindowIdFromWindow() discussed in the other thread, we managed to integrate the Windows App SDK in an unpackaged app without using Visual Studio as follows:

• Install Windows App SDK:

  :: download Windows App SDK NuGet package
  nuget.exe install Microsoft.WindowsAppSDK -OutputDirectory %cd%
  
  :: generate headers from Windows Metadata files
  cppwinrt.exe -out include-gen -ref sdk -in Microsoft.WindowsAppSDK.1.0.0\lib\uap10.0 -in Microsoft.WindowsAppSDK.1.0.0\lib\uap10.0.17763 -in Microsoft.WindowsAppSDK.1.0.0\lib\uap10.0.18362

• Add Microsoft.WindowsAppSDK.1.0.0/include and include-gen to header search paths.
• Link against Microsoft.WindowsAppRuntime.lib and Microsoft.WindowsAppRuntime.Bootstrap.lib.
• Bundle Microsoft.WindowsAppRuntime.Bootstrap.dll with app.
• Call MddBootstrapInitialize() at runtime as explained here.

[triplef]

Deployment issues in packaged app

We actually want to use this in a packaged app, but we’re running into some issues with the deployment following this documentation. Here is what we did so far:

• We added a package dependency to Microsoft.WindowsAppRuntime.1.0 in our AppxManifest.xml:

  <Dependencies>
    <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.18362.0" MaxVersionTested="10.0.19044.0" />
    <PackageDependency Name="Microsoft.VCLibs.140.00.UWPDesktop" MinVersion="14.0.24217.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
    <PackageDependency Name="Microsoft.WindowsAppRuntime.1.0" MinVersion="0.318.928.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
  </Dependencies>

• At runtime, we’re calling DeploymentManager::GetStatus(), which returns DeploymentStatus::PackageInstallRequired.
• So we call DeploymentManager::Initialize(), which returns DeploymentStatus::PackageInstallFailed with extended error 0x800700E8 (ERROR_NO_DATA).

I am guessing that we are again missing some other step performed by Visual Studio.

@DrusTheAxe any idea what we could be missing here?

[triplef]

I’ve posted this as its own follow-up discussion: #2139.

[DrusTheAxe]

@sachintaMSFT for follow up re the ERROR_NO_DATA