Setting up my dev environment for Windows App SDK is too tedious.

[dhoehna]

I want to point out issues I had when setting up a project to use Windows App SDK. Because, if I'm having these issues, I bet other developers are facing the same issues and walk away from Windows App SDK.

Setting up my dev environment for developing apps that use Windows App SDK is too cumbersome because I couldn't easily find the solution to my problems online.

Here are the problems I faced, what the symptoms were, and how they were fixed.

First scenario: Making an unpackaged C++ app that used Windows App SDK and following this guide.

1. VS can't find the header files. VS could find the winrt folder in Windows App SDK 1.1 and some other winrt headers.
   1. Solution was to the cppwinrt nuget package. No where does the page say "Make sure to include CppWinrt." I get it, some people might think "Windows App SDK uses CppWinrt, naturally the CppWinrt package also needs to be downloaded." I get that. However, for new developers, and new developers to either Windows App SDK or CppWinrt, the additional step of "Downloading CppWinrt" might not occur naturally.
2. These errors when WindowsPackageType is set to none: Project "AppLifeCycleTest" targets platform "Windows", but references SDK "Visual C++ 2015-2019 Runtime for Universal Windows Platform Apps v14.0" which targets platform "UAP". and Project "AppLifeCycleTest" targets platform "Windows", but references SDK "Visual C++ 2015-2019 UWP Desktop Runtime for native apps v14.0" which targets platform "UAP"
   1. Solution: Include <WinUISDKReferences>false</WinUISDKReferences> in the .*proj file.
3. Bootstrapper could not find any Windows App SDK files.
   1. Solution: Install Windows App SDK via the installer. Totally forgot to install all the Windows App SDK packages. Again, nothing in the tutorial. How did I find the installer? From the page mentioned above: Click on Release Channels and Release Notes -> Click on the version for latest release for stable -> Click Download installer.

Second scenario: Making a packaged C++ app that uses Windows App SDK and is built with Desktop Bridge.

1. Class not registered error at runtime.
   1. Solution: Add a Package Depndency to the Windows App Framework package. Doing this is not straight forward.
      1. Install the framework package, if not installed already.
      2. run get-appxpackage to find the framework package.
      3. Add a package dependency node to the package manifest.
      4. Copy the Name, publisher, and min version over from Powershell to the manifest.

As I said above. This post is to bring to light some of the issues faced when developing with Windows App SDK.

I'll follow up with this post by engaging the documentation team to add these pointers.

EDIT:
Didn't mean to post this in questions. I just wanted to start a discussion.

EDIT 2:
When looking up self-contained deployment I found this that does mention having to declare a package dependency to the framework package.

EDIT 3:
Made issues to track these.
CppWinrt needs to be installed, else VS can't find Windows App SDK headers.

Cryptic errors when WindowsPackageType is set to none.

Bootstrapper crashes if a package can't be found.

Docs for adding Windows App SDK to an existing project does not instruct devs to depend on the framework package.

[dongle-the-gadget]

I think that the templates should have included C++/WinRT already, and also, forcing the Windows App SDK package to also install C++/WinRT on every installation would be ridiculous (why would I need C++/WinRT if I'm using C#).

For the second scenario, shouldn't VS handle MSIX dependencies already?

[dmachaj]

I also got bitten by the "class not registered error at runtime" problem when converting a project from WinUI2 to WinUI3. I had to enable loader snaps to figure out which module could not be loaded and then it took a while to figure out why it couldn't be loaded. That took at least an hour or two along with a lot of debugging expertise.

[dhoehna]

Made an issue: Windows App SDK does not automagically update the framework package reference.