Microsoft-ui-xaml: 📞👩‍💻 WinUI *Bonus* Community Call - Preview 1 Q&A

[anawishnoff]

This community call Q&A session has ended.

See the recording here: https://aka.ms/winuibonuscall

---

Now that you've all had the chance to play with Preview 1 a bit, we are planning a special bonus edition of the monthly WinUI Community Call - an hour-long Q&A live stream session to answer all of your burning questions about WinUI 3 Preview 1!

Comment below on this Github issue with all of your questions 👇

Details

Date: Tuesday June 2, 2020 (NOTE: this will be taking place on a Tuesday rather than our regularly-scheduled community calls that take place on Wednesdays).
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 Q&A directly with members of our engineering team.

Format

In this call, we want to answer all of your questions about WinUI 3 Preview 1. We won't have any agenda or guest speakers on the call - we'll be spending the whole time answering your questions.

We will have both engineers and program managers on this call, so feel free to ask product/vision related questions and/or in-depth technical questions! We'll also have team members on the call from the Windows Community Toolkit, so feel free to ask any questions you have about WinUI 3 Preview 1 + WCT 8.0 Preview 1.

Please note that we likely won't be able to answer questions that are specific to your app (i.e. why doesn't this work?) so please try to ask questions that would have answers that are beneficial for all to hear. 😊

Ask away!

[michael-hawker]

🦙 The Llama will be there!

[MuziburRahman]

How the questions will be taken, leaving a comment here or in the youtube chat?

[electronic-dk]

Can we expect more first party apps from Microsoft based on WinUI 3? Be it new apps or updates of existing ones.

Cheers, thank you for all your work!

[anawishnoff]

@MuziburRahman You can do either 😊

[MuziburRahman]

Is there any limitation for Win2D in Win32 apps using WinUI ? If so, is there any plan to bring it to win32? Direct2D is already available for win32 apps AFAIK.

[MuziburRahman]

Is there any plan for an API to generate PDF? ( #672 )

[michael-hawker]

Is there any limitation for Win2D in Win32 apps using WinUI ? If so, is there any plan to bring it to win32? Direct2D is already available for win32 apps AFAIK.

🦙 There's an issue on the Win2D repo tracking WinUI support here.

[shaheedmalik]

Is there an update on faux acrylic?

[terrycox]

The Windows.UI.Xaml namespaces are defined in the WinRT API, and Microsoft.UI.Xaml namespaces must be explicitly declared in Xaml and code-behind to access them. For example, if I use Preview 1 to create a WinUI in UWP app, App.xaml's Application and ResourceDIctionary classes are from the Windows namespaces, as are Page, StackPanel and Button in MainPage.xaml. If WinUI namespaces are to replace the Windows.UI namespaces, how are you going to resolve this?

[mdtauk]

I assume the source for all those will move to Microsoft.UI.Xaml before launch

[terrycox]

What I'm thinking is that as long as the Windows.UI.Xaml namespaces are in the API instead of the Microsoft.UI.Xaml namespaces, you'll have to manually declare them, such as by adding xmlns:mux="using:Microsoft.UI.Xaml" and xmlns:muxc="using:Microsoft.UI.Xaml.Controls" statements to xaml files and then prefixing each control, for example, '<muxc:StackPanel' or ' Failing to do so will have you still referencing the ones in your UWP project. I'm assuming the Windows.UI.Xaml namespaces will have to come out of or get replaced in the API. My question is how the team is going to address this down the road. Of course, my understanding may be flawed and there may be a simpler way to go.

[cirrusone]

Will we be able to develop using Rust and WinUI? Any ideas on timescales and what that might look like, eg within VS/VS Code etc?

[alvinashcraft]

🦙 The Llama will be there!

Does the Llama have any tips for building the WCT on the branch for preview 1? I'll admit, I haven't tried very hard yet. I pulled the code down, made sure the right workloads were installed in VS, and pulled the packages. I have a bunch of errors but not handy. I'll gather them up for tomorrow.

[Pinox]

Feeling slightly confused here with WinUI3.0 and .Net 5 versus the current UWP model ;))

It seems that MS is recommending developers to use Winui3.0 with .NET 5 or that it is the future of desktop development for Windows. If I do that and I would luv todo that because I think WinUI3.0 / .NET 5 will be multiple times more performant than running a UWP app in the sandbox what happens then to the cross platform story of UWP apps that's suppose to works cross platform / device including XBOX. It seems that anything UWP is on "life support". So how does WINUI3.0 / .NET 5 fit into or link to cross device (windows 10 ) traditional UWP targets ?

If you say that pure desktop is WINUI3.0 / .NET 5 and cross platform is
UWP / WINUI3.0 is there a roadmap to give us one project solution from where we can target the different devices similar to the .NET MAUI roadmap ?

Therefor we have one project with all the different target configuration of the different devices.

proj file

• winui3.0 desktop app configuration
• Windows Store configuration (xbox , windows 10 , IOT)
• WINUI 3.0 Views
• Source Code.

Also , with the windows package manager on the horizon will the Windows Store become a shell / front end of the package manager ? That would make the most sense to me then with windows 10X virtualization every app on the "windows package manager" can run in a sandbox or on the wire. Giving an end user the option to select sandboxed versus no-sandbox apps from one source (windows package manager) would be super awesome as the end user can then pick an option that suits his needs.

The sandboxed environments of the traditional Windows Store and Windows 10X is starting to overlap. Windows Store deployment versus "windows package manager" is also overlapping. So MS is making this very confusing for developers that's trying to navigate between all the moving parts.

I would appreciate if MS can give us some direction here of what might potentially happen to the Windows Store / Windows Package Manager / Sandboxed Apps and how this relates to the best strategy moving forward with WINUI3.0 / .NET 5 and cross device ?

[michael-hawker]

🦙 The Llama will be there!

Does the Llama have any tips for building the WCT on the branch for preview 1? I'll admit, I haven't tried very hard yet. I pulled the code down, made sure the right workloads were installed in VS, and pulled the packages. I have a bunch of errors but not handy. I'll gather them up for tomorrow.

@alvinashcraft did you follow the steps here? The WCT preview only works for WinUI 3 Desktop apps currently. If you're still having trouble, feel free to add a comment with your environment/error details to our issue over on the Toolkit repo. Thanks!

[stevenbrix]

@terrycox to answer your question, we will be switching to using Nuget delivered metadata for the Windows SDK that doesn't contain the Windows.UI.Xaml types.

However, even today you shouldn't need to define the namespaces like that, the default namespaces should now include Microsoft.UI.Xaml. Can you share your repro project?

[stevenbrix]

It seems that MS is recommending developers to use Winui3.0 with .NET 5 or that it is the future of desktop development for Windows. If I do that and I would luv todo that because I think WinUI3.0 / .NET 5 will be multiple times more performant than running a UWP app in the sandbox

@Pinox we still very much believe in UWP. Kevin Gallo said if he were to create an app today he'd start with UWP. WinUI3 in Desktop is an ask from many customers who find that UWP doesn't meets their needs due to the restricted sandboxed environment that the apps run in.

what happens then to the cross platform story of UWP apps that's suppose to works cross platform / device including XBOX

This is precisely why we are still pushing UWP! WinUI in Desktop apps won't run on XBOX since they are desktop only.

Windows Store deployment versus "windows package manager" is also overlapping.

I totally hear you there, and I think it ultimately depends on your type of customers. Most consumers aren't comfortable in the command line, so if I was targeting that line of customers, I would stick to the store. But if I were writing a tool for developers, or my app was used in an enterprise setting, then winget would make a lot of sense.

[alvinashcraft]

@alvinashcraft did you follow the steps here? The WCT preview only works for WinUI 3 Desktop apps currently. If you're still having trouble, feel free to add a comment with your environment/error details to our issue over on the Toolkit repo. Thanks!

Thanks, @michael-hawker. I'll give it another go this weekend. I've got a chapter dedicated to WCT in my Learn WinUI 3 book. I'll be writing the first draft of that chapter in a couple of weeks, so based on what's currently there, I will probably need to focus on WCT with WinUI 3 + Desktop apps to include some sample code.

[jschroedl]

What milestone could we expect to be able to create more than one top-level window with WinUI content from Win32?

[jschroedl]

Will there be a sample demonstrating how to combine WinUI with Direct2D?

[alvinashcraft]

Do you plan to update the roadmap soon? Do you know when you will know which features will make it to the go-live Preview 4 release this fall?

[ijsankar]

@Pinox winget doesn't host any packages it is only a frontend. But the store does. winget enables users to install an app from a source using scripts for easy deployment . It also allows installation of UWP applications. So it never creates a problem with 10x or sandbox. Windows store or msix offers a clean packaging but not a sandbox. It is the UWP model offering the sandbox.

[terrycox]

You can see the namespace issue by simply using the Preview 1 UWP template, building the project, and browsing it's files. Assuming Intellisense is reporting correctly, they are all in Windows.UI.Xaml namespaces.

[Pinox]

@stevenbrix thanks for your reply. I think my impression comes from the fact that WinUI3.0 / NET 5 already works and UWP with .NET 5 is a work in progress with no definitive preview date except that it will launch with .NET 5.

For me the best scenario will be to use the most performant channel for desktop apps on windows 10 and I think it is safe to say that it will not be UWP sandboxed apps. I also want to add com interop to my desktop app so the WinUI3.0 / NET 5 will probably suit my app better going forward but I don't want to lose the cross device capability of UWP apps. Therefor my reference to a ".net maui" type project structure where you can target both (WinUI3.0 / .NET 5 + UWP)

What I don't understand is why does the Xamarin team get to unify all the projects into one with .net maui. Why can't this also be the reality on the rest of the ecosystem UWP + Winui3.0 + Blazor + Uno. One Project with the different config + views for the underlying platforms. No more shared dll's / Shared projects to reuse the code between the different projects. It will make for a much more performant architecture overall especially with one BCL.

@ijsankar my understanding was that the windows package manager will point to a "Microsoft repository" but potentially also to any other repo. therefor 2 MS repo's (package manager repo + store repo) seems like a duplication that is probably going the change going forward. I might be wrong in my understanding when I read about the MS repo. I understand the differences in the sandboxed apps. I am essentially posing the question why can't the "windows package manager" give us the option to install sandboxed or non-sandboxed apps. It will make for a much better ecosystem and the windows store front end UI can be an optional UI for the general end user on the "one Microsoft repo".

I might be jumping the gun here with the hope that we can see the same unification of architecture like the .net maui roadmap judging by the maturity and progress of WinUI3. I just think this is a golden opportunity to create the same "magic" that the xamarin team is doing in unifying the ecosystem.

[stevenbrix]

You can see the namespace issue by simply using the Preview 1 UWP template, building the project, and browsing it's files. Assuming Intellisense is reporting correctly, they are all in Windows.UI.Xaml namespaces.

@terrycox I think I see what's going on. The Xaml intellisense is hardcoded to use Windows.UI.Xaml for UWP projects. This is a known issue, and we plan on addressing it by Preview4.

Here are some screenshots to show you what I'm seeing.

Xaml Intellisense (which is incorrect):

C# Intellisense (source of truth):

[stevenbrix]

For me the best scenario will be to use the most performant channel for desktop apps on windows 10 and I think it is safe to say that it will not be UWP sandboxed apps. I also want to add com interop to my desktop app so the WinUI3.0 / NET 5 will probably suit my app better going forward but I don't want to lose the cross device capability of UWP apps. Therefor my reference to a ".net maui" type project structure where you can target both (WinUI3.0 / .NET 5 + UWP)

@Pinox as I understand things, the single .NET Maui project structure doesn't change the platform targets or runtime behavior, it's just a simplification in development.

Are you saying you want to write a single app that will run in the AppContainer on XBOX/10X/HoloLens, but when on Desktop not run in the AppContainer?

[terrycox]

Ah. Thanks.On Jun 2, 2020 3:30 PM, Steve Kirbach [e-mail] wrote:

You can see the namespace issue by simply using the Preview 1 UWP template, building the project, and browsing it's files. Assuming Intellisense is reporting correctly, they are all in Windows.UI.Xaml namespaces.

@terrycox I think I see what's going on. The Xaml intellisense is hardcoded to use Windows.UI.Xaml for UWP projects. This is a known issue, and we plan on addressing it by Preview4.
Here are some screenshots to show you what I'm seeing.
Xaml Intellisense (which is incorrect):

C# Intellisense (source of truth):

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.

[michael-hawker]

@alvinashcraft awesome, if you run into any issues, let us know on that linked issue in the Toolkit repo. Always happy to help!

[Pinox]

@stevenbrix yes , the simplification in development is what I am referring to.

Are you saying you want to write a single app that will run in the AppContainer on XBOX/10X/HoloLens, but when on Desktop not run in the `AppContainer?

No , you will still get an appx for UWP and a exe for WinUI3.0 desktop

this is .net maui

this is what i am proposing :

As a long term goal it would be great to actually combine .net maui and my proposed solution above then there is no need for seperate libraries (dll's) or shared projects in your code where everything gets compiled into the main app for the respective platform. Obviously then each "platform section" in the image above will have it's own defined view.

So now development in the .net ecosystem becomes a "view + config" on the common code in one project. WinUI3.0 / .NET + UWP + Blazor + UNO + Android + iOS is simply now a "view + config" on the common code within the same project.

[michael-hawker]

@Pinox is there a MAUI issue somewhere where they talk about the Platforms tree?

I see things being more useful to be displayed underneath the file:

   📁 Helpers
      🔽 BluetoothAdapter.cs
         - 🤖 Android
         - 🍎 iOS
         - 🐱‍👤 Windows
   🔽 MainPage.xaml
       ▶ MainPage.xaml.cs

Clicking on the file itself would just take you to whatever current platform you have selected for debugging, but you could still drill-in to pull up the alternates (and they'd show up in search of course still).

[Pinox]

@michael-hawker agree , that will also be perfect. Was just using the maui image , as I think uniformity is important in the .net ecosystem, but the important thing here is you are unifying UWP + Winui3 Desktop into one project. That and the fact that having most code in the same project will probably make things more efficient in Visual Studio , should increase performance and just make things generally way simpler as you compiling down to one executable for your own code.

I was reading an article on https://codetraveler.io/build2020/

This section catch my eye in the article above

Will .NET MAUI and Blazor be unified?
Stay tuned! No official plans yet, but we're looking into the possibility >

So if Blazor + .NET Maui is potentially on the cards where are UWP and WinUI3 Desktop ??

[stevenbrix]

@Pinox, that's certainly interesting! I don't think we'll have something like this for WinUI3 timeframe, just because we're trying to support .NET5 and Maui won't be ready until .NET6, but this is something we could consider for Project Reunion if it made sense. Can you file an issue on https://github.com/microsoft/ProjectReunion? That way the appropriate people will see it and can respond.