👩‍💻☎ October WinUI Community Call (October 21, 2020)

[anawishnoff]

Join us for our October Community Call! The call is a live-streamed event and can be watched on YouTube using this link:

https://www.youtube.com/watch?v=pzM1it35nbc

Details

Date: Wednesday October 21, 2020
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. In this month's call, we'll be welcoming one of our ecosystem partners as well as some internal members of the WinUI team.

Q&A: At the end of every community call we have a Q&A session where our team and guests answer your questions about all things WinUI. Ask your questions in the comments of this issue! If any questions come up during the call, you can ask them live in the comments as well.

Agenda
Intro, updates on WinUI with @anawishnoff and @ryandemopoulos
New & upcoming controls with @MarissaMatt and @gabbybilka
Developer tooling and experience updates with @JeanRoca
Why C#/WinRT? with @stevenbrix
WPF Updates with @predavid-zz
Ecosystem Spotlight: SyncFusion!
Q&A

Leave your questions below as well as general topics you'd like to hear about on the call!

[AzizAlqasem]

WinUI team,

Would you please discuss the possibility of adding Python support to WinUI3. Below is a proposal that was written by @freakboy3742 :
Proposal: Add Python support to WinUI3

Thank you,

[AathifMahir]

What's the future of UWP, Since UWP is superior and modern platform than Win32. Is UWP going to get underhood improvements and new features in the future or else we need stay with what we have now and just keep using win32 for Advanced App Development that UWP doesn't support?

[shaheedmalik]

What is the status of adding a faux AcrylicBrush to represent the HostBackdrop AcrylicBrush functionality in 3.0 until the proper fix is done?

#2236 (comment)

Then a faux version of the effect needs to be made in the mean time until the correct effect is worked out. The incremental changes of Fluent Design in the past led to the current inconsistency problem that Windows 10 is currently experiencing. If the whole point of WinUI 3 is to fix it, then creating a problem such as this defeating the whole purpose of consistency. Apps with acrylic and without is one of the biggest inconsistencies in Fluent Design.

[nnemkin]

Visual layer seems to be missing two crucial features: hit testing and text display. Are there plans to improve these areas? What are the best practices for text display and input handling using the existing Windows Composition API? (No UWP, Win32 only).

[massijay]

When templates for icons/tiles will be available? (Issue #2307)

[carmineos]

An update on multi-window support and eventually on a DockManager control (#668) would be nice!

[kmgallahan]

The number one thing I want is a temporary solution for using .NET 5 with UWP & WinUI 3.

I don't care how janky it is for now - make it desktop only, no MS Store submissions, MSIX only, "not officially supported", manual editing of solution files, no VS templates, whatever you need to do.

Otherwise, being a UWP developer over the next 1-2 years is just going to be horribly painful:

❌ No .NET 5
❌ No EF Core 5
❌ No C# 9
❌ Partial C# 8
❌ Continue dealing with .NET Native idiosyncrasies
❌ Looming dread of either a massive refactoring to adopt the above later, or never refactor and miss out on the future of the ecosystem
❌ Continually thinking about "well maybe I'll be able to use X next year...", ad infinitum

If you don't foresee a temporary solution like this being available in the next 6 months, then please, just be honest and tell us. I'd rather bite the bullet and move to Win32 dev if that means I get to stay current with the .NET ecosystem.

[mrlacey]

Can you provide an updated estimate of when a version of WinUI3 with support for production apps will be released?
Is there anything that will prevent apps built with preview3 being submitted to the Store before a GA release?

[mrlacey]

Previously, when discussing the changes to the roadmap it was explained that the reason for you doing less frequent preview releases was due to the amount of time and effort required to produce a release. The current "wisdom" around DevOps and releases is that if they are hard you should do them more often so that they become easier.

• Was this concept considered when plans were made to slow releases?
• If you keep to the plan of fewer releases (because they're difficult / time-consuming) what will this mean for preview releases once 3.0 has "shipped"? Will preview releases of 3.1, etc. be few and far between as well?

---

Context
My reason for asking is because the requirements of WinUI3 preview2 (version of .NET5 SDK, version of VS, etc.) make it very hard to keep up to date with the latest developments needed for other platforms or to get features and security fixes when other dependencies are updated.
Being unable to keep a dedicated machine for WinUI3 development means I'm unable to experiment and try out features/functionality because other (paid) work requires me to update to versions of tools I can't have side-by-side with what's needed by preview2.
For example, if there was a preview of WinUI3 that was compatible with the latest VisualStudio release and .NET5rc2 I'd be able to try more things out with it and provide more feedback to you.

[mrlacey]

Are there any plans, details, or information available relating to analytics services support for WinUI3 app?

Ideally I'd like to see an official SDK for integrating directly with (Azure) Application Insights, but would settle for App Center support, knowing exporting from App Center is possible.

[pjmlp]

No question, more of a feedback kind of comment, feel free to adress it, discuss it privately or whatever.

The way we have multiple reboots since Windows 8 introduction, first with single project per deployment target, then the initial unification via UAP, followed up by UWP and now Reunion.

Alongside dropping WinJS, never caring for exposing certain COM APIs to .NET devs, but at least we had C++/CX to write our own bindinds, which was C# developer friendly in regards to developer productivity.

A productivity that was completly disregarded as the ATL/WTL C++ forces managed to replace C++/CX with C++/WinRT, without any sort of Visual Studio tooling support for IDL files, that we have to manually copy and merge around, with the same confort as using Notepad.

Aparently these kind of warts for .NET developers forced to use C++ for the UWP APIs not exposed as .NET projects are to be acceptable in the hope that someday in 6 years or so, ISO C++ WG24 accepts the necessary language features for the Visual Studio team to replicate the productivity of 2012 C++/CX tooling.

Then we get undefined roadmaps regarding the future of UWP and .NET Native, in what to seems yet another couple of signs that with Reunion, the bigger plan is to rescue what it is possible from UWP, go back to the Windows 7 like development model and pretend that whatever was started with Windows 8 never happened.

Thing is, there is still plenty of WPF like features missing from WinUI, and many of us aren't willing to do yet another rewrite, regardless of whatever cool features WinUI might have. Personally I don't care about the continuous advertising it is written in C++, that is something for MFC guys, which might not be too found of the newly found love for east const anyway.

I would rather have seen more .NET Native love.

Currently, like many Windows developers, I am approaching rewrite fadige, and just sticking to the tried and true traditional Forms/WPF stack, with their existing tooling and component libraries.

I acknowledge that the current teams aren't responsible for the current state of affairs, and many hands are responsible for these reboots and continuous change of direction during the last eight years, so just some food for thought, which can be adressed to the audience at large (I am not the only one feeling like this), discussed internally, or just ignored as we might be an irrelevant minority on Windows roadmap.

[Marv51]

What are the issues or reasoning behind doing very big milestone previews in contrast with more a faster preview release cadence?
Projects adopt different release speeds, all the way from no previews at all to nightly builds. For WinUI 3 you chose 3-5 months between previews. What do you feel is the advantages of that?

[hansmbakker]

The way we have multiple reboots since Windows 8 introduction, first with single project per deployment target, then the initial unification via UAP, followed up by UWP and now Reunion.

Then we get undefined roadmaps regarding the future of UWP and .NET Native, in what to seems yet another couple of signs that with Reunion, the bigger plan is to rescue what it is possible from UWP, go back to the Windows 7 like development model and pretend that whatever was started with Windows 8 never happened.

I acknowledge that the current teams aren't responsible for the current state of affairs, and many hands are responsible for these reboots and continuous change of direction during the last eight years, so just some food for thought, which can be adressed to the audience at large (I am not the only one feeling like this), discussed internally, or just ignored as we might be an irrelevant minority on Windows roadmap.

Agree about the direction-shifting. "UWP is the way to go" was a clear message that got blurred afterwards.

A clear direction, less vague timelines, and also: alignment inside Microsoft teams to follow that direction themselves (not really the case now - for example see Teams where somebody decided it was a good idea to use Electron, being slow as a result), would be greatly appreciated.

I am not an Apple fan, but I have to give them a +1 for pulling off technology transformations (e.g. from Obj-C to Swift, from PowerPC to intel and now to ARM) in a clear and aligned way.

[Chiramisu]

I have a VERY legacy WinForms app built on .NET Framework 3.5. I'm trying to plan my migration path with WinUI 3 as the end goal. I've found these articles. Am I on the right track or going in the wrong direction? I need to modernize this desktop app, hopefully with the flexibility to make it cross-platform later on, depending on business needs.

1. Migration Guide to get into 4.x - see "If you have a .NET Framework 3.5 app"
2. Retargeting to get to a modern 4.x
3. Porting from .NET Framework to .NET Core - using the Analyzer and try-convert

I assume that final step would more or less get my code base in parity with .NET 5.

[JeanRoca]

No question, more of a feedback kind of comment, feel free to adress it, discuss it privately or whatever.

The way we have multiple reboots since Windows 8 introduction, first with single project per deployment target, then the initial unification via UAP, followed up by UWP and now Reunion.

Alongside dropping WinJS, never caring for exposing certain COM APIs to .NET devs, but at least we had C++/CX to write our own bindinds, which was C# developer friendly in regards to developer productivity.

A productivity that was completly disregarded as the ATL/WTL C++ forces managed to replace C++/CX with C++/WinRT, without any sort of Visual Studio tooling support for IDL files, that we have to manually copy and merge around, with the same confort as using Notepad.

Aparently these kind of warts for .NET developers forced to use C++ for the UWP APIs not exposed as .NET projects are to be acceptable in the hope that someday in 6 years or so, ISO C++ WG24 accepts the necessary language features for the Visual Studio team to replicate the productivity of 2012 C++/CX tooling.

Then we get undefined roadmaps regarding the future of UWP and .NET Native, in what to seems yet another couple of signs that with Reunion, the bigger plan is to rescue what it is possible from UWP, go back to the Windows 7 like development model and pretend that whatever was started with Windows 8 never happened.

Thing is, there is still plenty of WPF like features missing from WinUI, and many of us aren't willing to do yet another rewrite, regardless of whatever cool features WinUI might have. Personally I don't care about the continuous advertising it is written in C++, that is something for MFC guys, which might not be too found of the newly found love for east const anyway.

I would rather have seen more .NET Native love.

Currently, like many Windows developers, I am approaching rewrite fadige, and just sticking to the tried and true traditional Forms/WPF stack, with their existing tooling and component libraries.

I acknowledge that the current teams aren't responsible for the current state of affairs, and many hands are responsible for these reboots and continuous change of direction during the last eight years, so just some food for thought, which can be adressed to the audience at large (I am not the only one feeling like this), discussed internally, or just ignored as we might be an irrelevant minority on Windows roadmap.

Thank you so much for taking time to continuously provide us with feedback. I want to assure you that your voice is heard and feedback like this is the only way we can commit to delivering an improved developer experience to the community. There is no such thing as an irrelevant minority in the Windows roadmap ☺

Before I address your response I wanted to give a really brief disclaimer that I am still very new to the team and there is a lot of history that I am still unfamiliar with. With that said, I will try my best to touch on some main points and hopefully provide you with some clarity.

With Project Reunion we are not attempting a reboot like we have done in the past. Instead, you should see it as a path forward so that every developer is able to use the latest tech that we are working on. @stevenbrix gave a great update on the plan we are developing for UWP and .NET in today's community call. I would highly suggest watching that if you have not already.

It is my understanding that we have been adding support for WPF features in WinUI 3. If there is a particular feature that you would really like to see please file a request in the WinUI repo, but also acknowledge that we might not get to it in the 3.0 timeframe. When 3.0 ships we will be ready to implement more features.

With WinUI 3 in preview we are still working on developing a story. This is why we are not encouraging production apps from migrating just yet. If you prefer Forms/WPF and they meet your needs I would encourage you to hold off on migrating until WinUI 3 is ready. Once XAML Islands v2 ships we know we will have a better story for this, but for now the timeline for this is post WinUI 3.0.

Thank you again for the feedback. Feel free to reach out to me on here or on twitter @jpthepm if you have any more thoughts or questions!

[Pinox]

Awesome to see some progress on UWP with .NET5 in the community call demo. Well done MS !!

[Marv51]

Question for next community call: Why was Windows 10 1803 chosen as the base line for supporting WinUI 3?

Both 1803 and 1809 now expire May 2021 with the extension of the 'extended support end date'. So by early 2021 when WinUI 3 is ready that leaves a couple months for these releases at most?

This seems curious to me, as the next release (1903) was also the minimum requirement for XAML Islands (v1).