WinAppSdk release notes call out using wil's co_await DispatcherQueue support, but it doesn't exist

[asklar]

See microsoft/wil#213 - filing here to track

The code was removed when syncing with the OS copy of wil since it conflicted with some WRL names.

@dunhor @jevansaks FYI

[asklar]

One option is to not add these helpers to wil which would remove the dependency on wil altogether, which is goodness. Instead, we could have a winappsdk/winiu3-specific header in windowsappsdk that you can bring in to your C++ app.

[dotMorten]

Yes. Totally that. This should be built-in and follow with the SDK they are there to support (which would have avoided this mess in the first place). It used to be built-in.

[asklar]

@oldnewthing is fixing this in wil in microsoft/wil#214

[riverar]

What do you mean "fixing this in wil"? Will this be included in the WAS/MUX headers/metadata? Or are we all stuck now ingesting the entirety of wil? (Microsoft.UI.Xaml.winmd describes a [Microsoft.UI]Microsoft.UI.Dispatching.DispatcherQueue)

[oldnewthing]

@riverar Good point. I'll make it so that cppwinrt_helpers.h has no dependencies on any other part of wil, so it's a freestanding header. You don't have to ingest any other part of wil.

[riverar]

Sounds good, although am curious what Microsoft.UI.Xaml.winmd will point to (for the DispatcherQueue type) after everything is said/done.

[asklar]

The winmd has no dependency on anything C++ specific, it's just WinRT type metadata. C++ projects will have to reference the wil nuget, and consume the header that Raymond is adding the definitions to.

[dotMorten]

The winmd has no dependency on anything C++ specific

The WinAppSDK package includes a set of header files. that automatically gets referenced. It would IMHO have made more sense including this there - after all we didn't need WIL in the earlier sdk builds but suddenly that's yet another dependency we need to pull in.

Not sure what I'm missing to see the benefit of moving some of the WinUI specific stuff away from the WinUI specific SDK

[riverar]

I'll open a separate issue as it's not directly related to this.

[oldnewthing]

The old WindowsAppSDK contained custom headers that injected a resume_foreground into the winrt namespace, which was a violation of the C++/WinRT naming convention. Meanwhile, wil had a replacement resume_foreground that addressed many of the defects in the winrt::resume_foreground. In theory we could have duplicated them here (in a presumably new third namespace?), but then you run into the problem of keeping the two versions in sync.

Basically, resume_foreground is not a feature of the DispatcherQueue itself, but rather a new feature built on top of the DispatcherQueue. That new feature is implemented by WIL. (C++/WinRT learned the hard way that building features on top of Windows Runtime objects is a slippery slope, and has realized that it's better to leave the higher-order features to other libraries. "Do one thing well, don't try to do everything.")

[dotMorten]

@oldnewthing Thanks for the detailed answer. Much appreciated. Although I don't like the developer experience this creates, it does make a lot of sense

[asklar]

I believe the only thing missing now is updating the release notes so they point to the new header / guidance. Tagging @zaryaf here too for that : )

https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/preview-channel#other-limitations-and-known-issues

If you want to co_await on the DispatcherQueue.TryEnqueue method, use the resume_foreground helper function in the Windows Implementation Library (WIL):

Add a reference to Microsoft.Windows.ImplementationLibrary NuGet package. Add the #include <wil/cppwinrt.h> statement to your code file. Use wil::resume_foreground(your_dispatcher); to co_await the result.

[oldnewthing]

@zaryaf The header is now <wil/cppwinrt_helpers.h>. You must include it after you include <winrt/Microsoft.UI.Dispatching.h>.

[LegendaryBlair]

Close this stale issue.