👨‍💻☎ WinUI Community Call: November 16, 2022

[SavoySchuler]

Please join us for the November 2022 edition of the WinUI Community Call. This event will be live-streamed to YouTube: https://www.youtube.com/watch?v=VeK2uhYoDXM

Details

Date: November 16, 2022
Time: 16:00-17:00 UTC (9:00-10:00am Pacific)

Anyone and everyone is welcome - no pre-registration is required.
This will be an informal interactive live stream directly with members of our engineering team.

Format

The community call is a call among the WinUI team that is live-streamed onto YouTube. We present on new updates, share information, welcome guests, and answer your questions.

Agenda

• Intro
• 1.2 Release Overview
• Spotlight Guest: Azure Communication Services
• Q&A

Q&A Code of Conduct

• To help ensure Q&A remains beneficial for the majority of the call's developer audience, please consider whether your question could be framed so that it might be more broadly relevant to our larger developer audience by ensuring it is reasonably concise, broadly beneficial, well-suited for the fast-paced live Q&A format, or able to spark open ended discussion.
• Please understand some questions are not well-suited for the fast-paced live Q&A format and should be filed as standalone Q&A discussions where they can be most appropriately handled. Excluding presentation topic requests, this generally includes requests for dedicated follow-ups or technically complex questions that require investigative time or expertise not included in this month's guest list.

Leave us your questions in the comments on this issue or live in the YouTube chat during the stream!

[pubtom]

What is the recommended .NET/C# technology to make Xbox apps and games?
As Xbox is not (and will not be) supported by WinUI3 & Windows App SDK. And WinUI2 & UWP will only get bugfixes. Means that Xbox has only the legacy WinUI2 & UWP technology left.

[pjmlp]

From XBox team themselves, you are supposed to use GDK, and plain Win32.

UWP apps and games are community-supported only; partners inside Xbox managed programs (Xbox, Xbox Game Pass, Xbox Game Streaming) should use Microsoft Win32 + GDK.

See https://github.com/microsoft/GDK

[Iucapad]

From XBox team themselves, you are supposed to use GDK, and plain Win32.

UWP apps and games are community-supported only; partners inside Xbox managed programs (Xbox, Xbox Game Pass, Xbox Game Streaming) should use Microsoft Win32 + GDK.

See https://github.com/microsoft/GDK

Simply terrible to go this path instead of focusing efforts to close the platforms gap.

[pubtom]

From XBox team themselves, you are supposed to use GDK, and plain Win32.

UWP apps and games are community-supported only; partners inside Xbox managed programs (Xbox, Xbox Game Pass, Xbox Game Streaming) should use Microsoft Win32 + GDK.

See https://github.com/microsoft/GDK

Thank you the info! However I'm more interested in the .NET/C# way (like it was in UWP or XNA Framework), so I have fixed my question.

[pubtom]

Will there be managed DirectX(especially Direct3D) support in the Windows App SDK? (Like XNA Framework or SharpDX were in the past)

[pjmlp]

C# developers time to keep those C++ skills up to date, is what this reply means every time it pops up.

[DarranRowe]

No, it means ask the right questions to get the answers you want.
Since the question was edited since my reply, then I am glad to say that pubtom understood my point.

[stevenbrix]

not sure if this his helpful, but the directx apis are available via the win32 metadata project: https://github.com/microsoft/win32metadata

[ShadowMarker789]

One can access all DX levels up to DX12 via interop packages like TerraFX.Interop.Windows or CSWin32.

I've made a purely managed DX11 swapchain to test it out, with a learning curve similar to C++ DirectX.

[pjmlp]

On Apple and Google platforms we get the managed bindings from the platform, here we need to rely on the community.

I guess better than nothing at all.

[pubtom]

Will there be an official fix for #5299 ?

[Scottj1s]

Unlikely - have you tried the suggested workaround?

[pubtom]

The workaround downgrade the UI with 0 corner radius.
It is not so professional to create a component that does not work by default because of this issue and suggesting to set some feature to zero to make it work. Just think about it!

[SeRgI1982]

Hi,

What about Unit Testing ?
There is an article about Unit Tests in WinUI (https://devblogs.microsoft.com/ifdef-windows/winui-desktop-unit-tests/) but there Debug Test does not work.

[Scottj1s]

Unit testing should be fully functional, with one caveat - a change in Windows App SDK 1.1 exposed a bug in Visual Studio that breaks unit tests: Windows App SDK 1.1+ Unit Tests not launching as Packaged
There is a workaround for that issue. If you're seeing something unique, please enter an issue.

[roxk]

I know open-sourcing WinUI 3 isn't going to happen soon. Given the slow rate of bug fixes and feature development, what can we do to help you get more resources to speed up development? Something like "signed petition to add more people to WinUI 3"? Feedback hub for WinUI 3? Or even...donation?

[SeRgI1982]

I wonder, how many people are working on WinUI (not community) ?

[saint4eva]

Support for writing UI in C#, instead of xaml?

[nikolayvpavlov]

1. When we can have a working global exception handling in WinUI 3? This is a real showstopper.
2. What about porting InkCanvas to WinUI 3?
3. The current speed of fixing bugs and implementing new features is troubling, to put it mildly. The team has spoken that Microsoft are very committed to WinUI 3, but actual progress does not support these statements.

[Scottj1s]

1. When we can have a working global exception handling in WinUI 3? This is a real showstopper.

The last bit of work for restoring this behavior has been checked in and is awaiting a release. Meantime, there are a couple workarounds documented here: Do_Abi_* event/callback handlers should wrap invocations with RoReportUnhandledError

[nikolayvpavlov]

Thanks, Scott! I will give it a try and report.

@MikeHillberg , if you can give me a hit on inking, it would be great indeed. I tried to find some low-level approach, but it is either using UWP islands (which is not possible in WinUI3 afaik) or deemed legacy (from the ages of Tablet PC). Is it InkDesktopHost I should look into? Many thanks!

[mpettit2253]

XAML User Interface and Ink overlaid on top of high-performance imagery and video

This issue is related to the 'What is the guidance for Xbox and PC Games' question above. I am faced with creating a new version of an interactive imagery and video analysis application on the PC. It seems as though WinUI 3 has deprecated the WinRT 8, 10 and 11 showcase features of ink and DirectX/Xaml integration.

Our target machines include the Surface Studio 2 (5k screen) and Surface tablets (low power) and Surface Hub type devices for analytic collaboration. Panning and zooming huge HDR images at >= 60 frames per second with shader pixel processing for dynamic range correction and colorization overlays seems to require a SwapChainPanel instead of a VirtualSurfaceImageSource.

However, dynamically creating the user interface elements like shapes, lines, text, buttons, and initial ink markings composited over the image pixels is perfectly acceptable using UIElements and SpriteVisuals running at 60FPS. The custom ink drying features are really useful for processing the user's ink input into graphical features integrated into the imagery (such as lines that draw 'underneath' of shadows cast by the sun). Unreal and Unity don't have such features, and our users really don't want the poor input-lag and clunky visual feel that Adobe gets using a cross-platform control framework.

These features exist fine in UWP. The UWP/DirectX integration (ie, composited together using transparency) seem to have been a fundamental feature of UWP. As of right now, the guidance appears to be 'those features are in bug-fix mode only' going forward. If they are being left out because nobody else used them, that's OK. Just please tell us clearly.

[BrunoBieri]

1. On the roadmap md file I can see until end of 2022. Can you already make a statement to the 2023 roadmap of the WinApp SDK?
2. As mentioned by others already, is there a plan to speed up bug fixes and implement new features you can share?

[BrunoBieri]

As mentioned in the community call by
@gabbybilka at 19 min 55 sec (https://youtu.be/VeK2uhYoDXM?t=1195) as well as by
@ryandemopoulos at 47 min (https://youtu.be/VeK2uhYoDXM?t=2820)
a kind of a roadmap/whats next could be summarized as:

• Rest of 2022 -> 1.2.x servicing releases (bug fixes for those issues of most impact and least risk)
• Starting January 2023 ->1.3 experimental releases and previews
• Targeting end of March/starting April -> Delivery of WinAppSdk 1.3 stable release

The exact details/features/content of the WinAppSdk 1.3 release are not yet locked down but in general they want to address mainly the long standing open issues in this repository as per Ryan.

[ackh]

Not directly specific to WinUI, but Windows App SDK in general:

Are you still using the Productboard that you announced here to guide development activities?

It seems stale, i.e. it still lists features as "planned" that are already shipped.

This question has been answered as commented below

[kmgallahan]

During the last call they mentioned the product board is no longer being used. It was established under/by Andrew Leader, and he left WASDK team earlier in the year.

[ackh]

Alright, thanks for the reply. I missed the last call and didn't follow up.

[ackh]

Again, not WinUI specific but this thread seems to be a good opportunity to ask:

1. Is the scope of the Windows App SDK to eventually make *all* UWP APIs available outside of UWP apps?
2. If the answer to 1. is no, which APIs will not be made available?
3. In a UWP app I have a QR code scanner that works well. In order to port this app to the Windows App SDK I need to have the DisplayRequest, CaptureElement, MediaCapture, BarcodeScanner and ClaimedBarcodeScanner APIs. Will these APIs be added to the Windows App SDK eventually? This question seems obsolete at the moment due to @DarranRowe's comments below.

I understand that you cannot give a timeline for any of this. I'm a developer myself so I understand that. But the big question mark for me is whether it is planned or not. To make the decision as a business to move to the Windows App SDK it is important to understand what is coming and what is not.

[DarranRowe]

The thing to remember is that not all of the UWP API need to be ported.
First, DisplayRequest is an API to request that power savings isn't activated while no activity isn't detected. This generally isn't needed for desktop applications, and if you want to stop power savings from happening, then there are other methods available. Remember, you are in desktop application territory here. Interestingly, DisplayRequest seems to be supported based upon Windows Runtime APIs not supported in desktop applications. MediaCapture, BarcodeScanner and ClaimedBarcodeScanner also seem to be callable based upon that same page.
Just because something is in the UWP API set, it doesn't mean that it is unavailable to desktop application. For quite a few of these APIs, the biggest requirement is that the application has to have a package identity, aka it needs to be a packaged desktop application.

Interestingly, as an example of this, the Visual Layer/Composition is available as Windows.UI.Composition and Microsoft.UI.Composition. If you want to use the composition API in a WinUI 3 application, you will be using the Microsoft.UI.Composition namespace. But if you were to use this in a regular desktop application then you would be using the Windows.UI.Composition namespace. The Windows App SDK/WinUI composition is missing the desktop window target class.

[ackh]

It's just not clear to me how I would access those objects. I tried to write a QR code scanner using C++/WinRT and Windows App SDK. Here's how that looks like:

The .idl file content:

namespace My.Company.Application
{
  unsealed runtimeclass ScannerView : Microsoft.UI.Xaml.Controls.UserControl
  {
    ScannerView();
  }
}

The .h file content:

#pragma once

#include "ScannerView.g.h"

namespace winrt::My::Company::Application::implementation
{
  struct ScannerView : ScannerViewT<ScannerView>
  {
  public:
    ScannerView() = default;

  private:
    winrt::Windows::System::Display::DisplayRequest                _displayRequest;
    winrt::Windows::UI::Xaml::Controls::CaptureElement             _captureElement;
    winrt::Windows::Media::Capture::MediaCapture                   _mediaCapture;
    winrt::Windows::Devices::PointOfService::BarcodeScanner        _barcodeScanner;
    winrt::Windows::Devices::PointOfService::ClaimedBarcodeScanner _claimedBarcodeScanner;
  };
}

namespace winrt::My::Company::Application::factory_implementation
{
  struct ScannerView : ScannerViewT<ScannerView, implementation::ScannerView>
  {
  };
}

The .cpp file content:

#include "pch.h"
#include "ScannerView.h"
#include "ScannerView.g.cpp"

namespace winrt::My::Company::Application::implementation
{
}

Attempting to compile that sample fails because neither BarcodeScanner nor ClaimedBarcodeScanner can be found. I have no idea what I would need to include to make these types available. My assumption at this point is that these types are just not available.

[DarranRowe]

Since BarcodeScanner and ClaimedBarcodeScanner are in the Windows.Devices.PointOfService namespace, did you include winrt/Windows.Devices.PointOfService.h?

There is no issue detecting those types or compiling with that header included.

[ackh]

@DarranRowe Resolving that issue was indeed as simple as including <winrt/Windows.Devices.PointOfService.h>. I think before you stated

The thing to remember is that not all of the UWP API need to be ported.

it hasn't really sunk into my mind that the APIs in the Windows namespace might be used as is. I was always looking for APIs in the Microsoft namespace and was silently assuming that one day, all APIs in the Windows namespace would be ported over.

I will try to port my QR scanner now and see how that goes.

Thanks!

[Scottj1s]

@ackh We acknowledge the confusion on which Windows.* namespaces are safe to use in Windows App SDK apps (alongside Microsoft.* namespaces), and are looking at better ways to assist the developer

[harvinders]

Could we please get an update on #6299. With the current state of WinUI 3 we are unable to create plugins with usercontrols in it, this I believe is a must feature for windows apps. We can't build serious apps without the ability to create UI plugins.

Current state

• There is a workaround by creating UserControls in code behind, also we need to create our own version of InitializeComponent for that control.
• However, there does not seems any workaround to define dependency properties or attached properties on the user control.
• Also, we are unable to use x:Uid and link string resources defined in resource file.

[DarranRowe]

With regards to this, there is a known issue with the default project settings for the Windows Runtime Component (WinUI 3) template.

With AppContainerApplication set to true, the component will look in the application root directory (where the .exe is) for its resources.

However, the files are not in that location:

If you modify the project so that AppContainerApplication is set to false, then the path that it generates to load the resources includes the subdirectory.

This is where the files reside.

So, while the project template is bad, there is a much easier work around. This should also mean that the pri file will be properly merged with the main resources.pri.

[harvinders]

@DarranRowe The issue #6299 mentions creating C# plugins and loading them through AssemblyLoadContext, this use reflection and would not merge the pri.

As you mentioned the changes to the project file create the correct InitialiseComponent, we are already doing this, but manually. Even after that change things are not working. We have to still create controls in the code behind.

Are you suggestion that instead of creating simple WinUI 3 library project one should create Windows Runtime Components for plugin? Can they be even loaded dynamically?

[MEK3DK]

This is also a showstopper for us. Even if there is a workaround, that is not acceptable. This is the most basic functionality, which should just work.

[Iucapad]

I wonder where would be UWP if you focused all your efforts to improve the platform instead of choosing another path and building back some parts of what was great in UWP apps to older frameworks.
I also wish at some point you change your minds again and bring WinUI 3 to UWP, so each app platform can evolve at the same time

[rick-palmsens]

What is the progress on supporting interactive controls (such as a button or a search bar) on the title bar?

[roxk]

ExtendContentIntoTitlebar is available already, as can be checked out in WinUI 3 gallery. If you are talking about down level windows 10 support (down to 1809), this is available in 1.2.

[ackh]

Visual Studio offers support to debug DirectX based applications via menu Debug, Graphics, Start Graphics Debugging as outlined here. This worked well when developing UWP apps that utilize DirectX to render content but does not work with WinUI 3 based apps. However, attempting to start the graphics debugger with a WinUI 3 app does not actually start the app and instead repeatedly shows the following warning:

Warning: capture layer appears to be hung.

When will the graphics debugger support WinUI apps?

[get-flat]

Any updates: #4419?

[ryandemopoulos]

No timeframe right now, but unlikely that it will be a part of the 1.3 release. It's relatively low priority compared to the long list of other requests we're trying to get to first.

[AndrewKeepCoding]

Can we expect #2508 to be fixed any time soon (next service release maybe)? or might take more time?

[ackh]

Issue #7911 makes WinAppSdk 1.2 useless for my app. Is anyone looking into this?

[MikeHillberg]

Yes, we're working on a fix, and there's a workaround for it in this comment

[ackh]

Issue #7924 describes that I'm getting a fail fast exception with WinAppSdk 1.2. This wasn't the case in 1.1.5 or earlier and I'm clueless how that exception relates to my code. I'd really appreciate if someone could look into this and provide some hints why this happens with 1.2.

[JuanMejiaVelez]

Transitioning from UWP to WinUI3 seems to have a few gaps in the latest version, specially related to Windows Runtime Components,
When creating a C# Desktop app with a few Class Library Projects all seem fine, but then, there are no Windows Runtime Components for C#, and when switching to C++ there is one for C++/WinRT but this project can't be reference from the C# side with a error (NETSDK1130) that indicates that direct references to winmd can't be made from .NET projects anymore and a link to this issue and how to address it.

Two questions?
Going forward,
What's the recommended approach within WInUI3 to create Background task projects for Store Apps to replace what UWP has?
What's the recommended way to invoke code that is written in C++ from within code that is written in C# (App or Class Library).

to me it feels odd that creating projects within the WinUI 3 environment code from C# can't communicate easily with code in C++
Blank App , Packaged (WinUI 3 in Desktop) C# --> Windows Runtime Component (WinUI 3) C++

[JaiganeshKumaran]

This is not an issue with WinUI 3 itself but with CsWinRT. Currently, to consume WinRT components, you need to manually create a projection assembly using the CsWinRT tool.

See: https://learn.microsoft.com/en-us/windows/apps/develop/platform/csharp-winrt/net-projection-from-cppwinrt-component.

[Scottj1s]

In addition, here is a sample background task implementation: Background Task C#/WinRT Authoring Sample

[Pinox]

With .NET 8 planning currently on MS agenda. Is there someone on the WinUI 3 team that can promote the idea of bringing "Blazor Hybrid" to native WinUI3 ? Currently BlazorWebView is only supported on Winforms & WFP. WinUI3 is supposed to be the future of Windows development but all these silo's still exist. Using WebView2 with Blazor is a much more complicated setup than using BlazorWebView directly. This will enable us to integrate Blazor tightly with native WinUI3 controls within the same app.

Return on investment in Blazor and WinUI3 will be significantly increased if we can reuse these investments in the same app.

[glanium]

TreeView is buggy and useless
Please fix #7887,#6585

[lhak]

Why did you not fix the touchpad regressions (#7572) for the stable release even though this issue was reported months ago when the first experimental release shipped?

[ackh]

@Scottj1s @MikeHillberg @DarranRowe Thank you all for taking the time to answer my questions, both here and during the call. Really appreciated!

And thanks for the effort you put into the Windows App SDK in general. I have to admit it is exciting to see how it is coming together.