Microsoft-ui-xaml: First WinUI 3.0 Alpha now available ๐Ÿš€๐Ÿ‘ฉโ€๐Ÿ’ป๐ŸŽ‰

Created on 4 Nov 2019  ยท  41Comments  ยท  Source: microsoft/microsoft-ui-xaml

WinUI 3.0 Alpha now available!

As mentioned in the community call last week we now have a super-early WinUI 3.0 Alpha build available!

We'd love it if you could try it out and let us know what you think about the direction and roadmap.

Please note that it's a very early prerelease and has lots of known issues and missing functionality so it isn't ready for shipping apps. Future previews and the first stable version of WinUI 3 in 2020 will add support for everything outlined in the roadmap.

Installation info

For installation info and known issues see:

WinUI 3.0 Alpha (November 2019)

There's a super-short survey with the download link - we'd love to know more about how you're interested in using WinUI.

Please try out the Alpha, let us know what you think and open issues if you run into any bugs that aren't listed already!

What's new?

The major updates so far are:

1) WinUI 3 no longer depends on Windows.UI.Xaml: the full Xaml framework and parts of the composition and input stack have been decoupled from the OS and ship via NuGet

2) WinUI 3 works downlevel! The Alpha works with min version 1803 (April 2018 Update)+ and we're working on expanding the supported version range. For example, new features like Lottie Animations exported from Adobe Illustrator and Input Validation via INotifyDataErrorInfo now work on a range of in-market OS versions:

image

Uno

In other exciting news we're also working with the Uno platform so that developers can bring their WinUI code anywhere WebAssembly runs โ€“ including Windows 7. For more info you can check out their recent blog post: https://platform.uno/WinUI-on-Windows7-via-UnoPlatform/

What's next?

As outlined in the roadmap we're hard at work getting WinUI ready for open source development, plus working toward a more complete preview, .NET Core support, and more!

discussion winui3ฮฑ

Most helpful comment

Wow!! The Uno bit enlightened my day!
That is freaking awesome! Congrats Microsoft and Uno ๐Ÿป

All 41 comments

Future updates will add support for additional project types and languages, including .NET Core 3.1+ and the desktop (win32) app model.

So is the alpha still running on .NET Native or .NET Core 3.0? If the former (assuming so due to dependencies), will 3.0 not be a target in the future?

The alpha works with .NET Native or C++ for now, and RTM will support .NET Core. Really it probably shouldn't say 3.1 at this point since we're still working out versioning with the .NET team but hopefully it'll be open source before then so it should be easy for everyone to stay up to date on what's going on ๐Ÿ™‚

When will the code be open?

@vitorgrs we don't have a firm date yet but we're working on it now - it's currently our main focus.

@vitorgrs we don't have a firm date yet but we're working on it now - it's currently our main focus.

Thanks!

Don't forget the Compact Sizing in WinUI 3. It was announced at probably build '18 but supports just 2-3 controls till now.

@MuziburRahman have you tried using the Compact style dictionary in WinUI 2 (and 3)?

https://docs.microsoft.com/windows/uwp/design/style/spacing#fluent-compact-sizing

It should automatically adjust various Text and List controls, ContentControl, TreeView, DatePicker, TimePicker, ComboBox, NavigationView, etc.

Are there specific other controls you think should be adjusted?

@jesbis Of course, what about RadioButton, CheckBox ?

@MuziburRahman those should also have compact margins already by default when using the compact style:

image

Wow!! The Uno bit enlightened my day!
That is freaking awesome! Congrats Microsoft and Uno ๐Ÿป

First I'd just like to say thanks to everyone involved in WinUI. WPF has been the most "cutting-edge" Windows UI framework that I've had the chance to work with in my career, generally because of the restrictions of UWP combined the usual legacy code problems that make modernising difficult, so I am really looking forward to using WinUI 3.0.

Everything I've read since first coming across the roadmap sounds great. The separation of XAML from the underlying app model is perfect, for example. Being able to soon use features like x:Bind for compile-time binding checks in WPF applications (or rather, applications using the Win32 app model I guess I should say) is something I've wanted for years and has been the main thing missing from XAML for me. I only recently discovered it was actually something that already existed in XAML, and has been enjoyed by UWP developers for a while.

On top of that, finally getting access to all of the nice controls that conform to Fluent Design, and having them available in WPF with XAML Islands, plus all of the other stuff โ€“ it's basically everything I've always wanted for Windows desktop development arriving at the same time. It looks like it's going to be so much easier to create Windows applications with a great look and feel right out of the box now. So thank you again.

I just have a couple of questions around timelines:

I think my first question would simply be, is it fair to say that it's unrealistic to expect any kind of production-ready version of WinUI 3.0 by February 2020 (even as a fairly stable pre-release)?

Basically, we have a project for an internal tool going on right now with the intended release date being in February 2020. I would love to be able to create it as a "pure" WinUI 3.0 app, because I think that will both reduce the development time of the UI significantly and result in a UI that wows the users well beyond anything they are expecting.

The next level of complexity though, is that in reality this new tool is most likely going to have to be created as an addition to an existing tool of ours, and that existing tool is built using WPF on .NET Framework 4.7.2.

With all that in mind, is my understanding correct that probably the best bet for us (in order to have a modern-looking, Fluent-based UI for the new tool at all) is going to be to:

  • Keep our existing application as a WPF application
  • Port it from .NET Framework 4.7.2 to .NET Core 3.1 (I believe this is needed to support the final point below)
  • Create UWP class libraries using WinUI 2.3 for the new tool's views (i.e. custom controls)
  • Use XAML Islands to host these modern views in our WPF application

The correctness of that approach would be my second "question". Knowing the existing tool as I do, I have my doubts that we're going to be able to get it onto .NET Core 3.1 anyway, and then of course there's the issue of the new and old UIs clashing too much, but I'm trying to keep my dream alive here...

Anyway, if a rough indication for those two questions is possible it'd be much appreciated.

Let me know if this is the wrong place to ask, but is there a migration path from current uwp apps to WinUI + dotnet core 3? Will the migration require code changes?

Will the Uno implementation be in a browser, or will it be possible to run the app in its own window?

Will the Uno implementation be in a browser, or will it be possible to run the app in its own window?

"Run your app on Chromium through Electron"

It seems that Electron will encapsulate the WebAssembly and run it.

@dpaulino We're looking at all options for migration to WinUI. Currently, we're seeing a migration path where all you'd need to do is target the WinUI nuget and search and replace "Windows.UI.Xaml" to "Microsoft.UI.Xaml" + small code changes for certain types that don't benefit from .Net's custom projections such as constructors for Color, Thickness or INotifyPropertyChanged, etc. Our goal is to make switching as easy as possible, so if the list of things you need to gets too involved, we'll definitely explore fixing that or adding tooling to make it painless.

@agoodwin thanks for the comments! We greatly appreciate the feedback - it's especially helpful to hear about what kinds of apps people are building and what features are important. We definitely aim to make it easier to develop modern native apps with WinUI 3.

If your release timeframe is only 2-3 months away then extending your existing app does sound like the most reasonable approach. If you're able to migrate to .NET Core (or alternatively write the new views in C++) and all of your users will be running the Windows 10 May 2019 Update or later then using Xaml Islands to host new views created with UWP Xaml + WinUI 2 can definitely be a good incremental step toward a future WinUI 3 solution if that ends up making sense for your app.

I can't wait for WinUI in win32/desktop with .NET Core!

WinUI 3.0's stable release will be the start. What happens after will make or break the platform in the longer term.

Will it speedily address the needs of developers from all camps?

Will inbox apps currently "stuck" in Win32 legacy UIs, be moved to WinUI?

Will "limited" UWP apps find better performance and new powerful capabilities, when released from the sandbox?

Will the dev story be clear and compelling to the big companies like Twitter, Facebook, Apple, Google - and bring apps to Windows in its various form factors.

And the biggest unknown will be how Microsoft converges its Windows and Android inbox and big apps to work seamlessly on Windows 10, 10X, Xbox Scarlet and Surface Duo's Microsoft flavour of Android?

@agoodwin thanks for the comments! We greatly appreciate the feedback - it's especially helpful to hear about what kinds of apps people are building and what features are important. We definitely aim to make it easier to develop modern native apps with WinUI 3.

If your release timeframe is only 2-3 months away then extending your existing app does sound like the most reasonable approach. If you're able to migrate to .NET Core (or alternatively write the new views in C++) and all of your users will be running the Windows 10 May 2019 Update or later then using Xaml Islands to host new views created with UWP Xaml + WinUI 2 can definitely be a good incremental step toward a future WinUI 3 solution if that ends up making sense for your app.

Thanks for the clarification, I didn't realise C++ was another option for short term usage of WinUI 2 without .NET Core, so that's good to know.

Realistically we probably shouldn't use C++ in the specific application I was referring to, but we do have some C++ stuff so it could be useful for that.

Anyway, it sounds like for now we should hope the migration to .NET Core works for us and then work from there. Thanks again.

off topic-ish:

after i read mdtauk's comment I realised that Google and Facebook don't even have any native apps for Windows (except Google Drive's backup). Facebook used to have UWP apps that were ports from iOS but they ditched them. I can imagine FB releasing native apps using react native once/if react-native-windows gets merged with react native

I'm interested in what Spotify and Adobe will do. Spotify relies on Electron (well actually Chromium Embedded Framework, same thing lol) and Adobe has a really old codebase (XD is a new app and is a UWP app). Ooh and add Microsoft Office to my little list. Office has an old codebase too.

I do not think support win7 by Electron is good way. Why we need to run in our platform but dependent on Electron.

@lindexi
It's better than nothing, when Win7 shouldn't be supported at all.
Also full backporting to Win7 is time consuming, so it's better to spend Microsoft resources to make WinUI better on Win10. IMHO.

I try to port a small program to WinUI 3 Alpha, and it surprises me that it lacks the DPI awareness... It's not by design, right?๐Ÿ˜‚

@Tirraon I total agree with your point. But this behavior will zip the WPF space in Win7. "Look at here, the UNO use Electron, the Electron is better than WPF ... "

But this behavior will zip the WPF space in Win7. "Look at here, the UNO use Electron, the Electron is better than WPF ... "

You're right, but every new-born framework may zip the old ones. UWP will zip WPF on Windows 10, and WinUI with Xaml island will zip it too.

But this behavior will zip the WPF space in Win7. "Look at here, the UNO use Electron, the Electron is better than WPF ... "

You're right, but every new-born framework may zip the old ones. UWP will zip WPF on Windows 10, and WinUI with Xaml island will zip it too.

I dont think the Electron is in dotnet technology stack. I am willing the UWP zip WPF but I dont like the Electron zip WPF.

Looks good. But I wonder to know when WPF XAML will replace the WinUI XAML because we want a universal modern user experience.

Looks good. But I wonder to know when WPF XAML will replace the WinUI XAML because we want a universal modern user experience.

Xaml Standard fizzled and died. WPF XAML is I think a 2009 spec, whereas WinUI XAML is 2006.

I hope .Net Core 5 and WinUI 5 could perhaps complete a transition to a unified and open spec 2021 XAML spec.

Any thoughts when a WinUI 3.0 alpha for Win32/Desktop will be available?
For work this is the only target that has enough features for our management software. Can't wait to dable in it there.

We don't have a firm date for the win32 preview yet but we'll let everyone know when we do!

I did not see AppWindow on the list of the currently not supported features, but it seems that the required APIs are currently missing.

@lhak sorry, thanks for pointing that out (and for trying the alpha!) - it's not currently supported. I just opened a PR to get it documented in the known Alpha limitations.

@jesbis (here)
The alpha works with .NET Native or C++ for now, and RTM will support .NET Core.

The problem is that C# 8 only works against .NET Core 3. Pretty big limitation in the alpha version.
Anyway, I'm looking closely and appreciate all your countless efforts ๐Ÿ’–

Will WinUI 3.0 work with WPF? If yes, will it work without XamlIslands? If no, will there be a choice to use it with C# and without UWP, and on something that does not run in sandbox?

Would love for the PermissionRequested event to be in there in an early stage as this is an important one for accessing camera and microphone in order to use WebRTC. Or is there a new way to handle the webcam and microphone permission request from the webview?

any news about WinUI3.0 with win32 app model?
I can't wait for it.

@amyhaber A WinUI Desktop preview with Win32 support is slated to be released around Build next week.

@amyhaber A WinUI Desktop preview with Win32 support is slated to be released around Build next week.

awesome!

@Felix-Dev when you say win32 are we now talking about a .net core build ?

@Felix-Dev when you say win32 are we now talking about a .net core build ?

AFAIK WinUI Desktop will support C++ and C# with .net core

@Pinox As @mdtauk said. Taken from the WinUI 3 roadmap:

image

AFAIK support to create a new WinUI Desktop app targeting the .NET Framework is not going to be added to WinUI Desktop.

Here is also a comment by @ryandemopoulos about the WinUI .NET story given in a recent community call.

Was this page helpful?
0 / 5 - 0 ratings