Announcing .NET MAUI in .NET 8 Preview 7: Keyboard Accelerators
.NET MAUI is now available in .NET 8 Preview 7 introducing keyboard accelerators, and more fixes and improvements. This is the final preview release of .NET 8 before we ship release candidates and the generally available (GA) release. We will celebrate that release as usual at .NET Conf, and the dates have been announced. Join us November 14-16, 2023 to celebrate the .NET 8 release!
Version 7.0.92 is the latest service release for .NET 7. During this time we are heavily focused on .NET 8 to make it the best release. Starting next release with RC1 you will be covered with a go live support license. We encourage everyone to consider using .NET 8 releases from this point forward.
Today’s release is brought to you by 25 contributors (bots included). We want to celebrate them all, especially first time contributors Lehonti Ramos, webwarrior-ws, molesmoke, and Aaron Galuzzi. Well done! We appreciate everyone’s contributions. See our contribution guide if you are interested in helping out.
Desktop Keyboard Accelerators
Keyboard accelerators enable you to assign keyboard shortcuts to any menu item, whether visible or not, and attach them to any UI element. For example, this page has a window level menu to which you can add an accelerator with the MenuItem.Accelerator attached property:
<ContentPage.MenuBarItems>
<MenuBarItem Text="File">
<MenuFlyoutItem Text="Preferences"
Command="{Binding PreferencesCommand}"
/>
</MenuBarItem>
<MenuBarItem Text="Products">
<MenuFlyoutItem
x:Name="AddProductMenu"
MenuItem.Accelerator="ctrl+a"
Text="Add Product"
Command="{Binding AddProductCommand}"
/>
<MenuBarItem Text="Add Product Category"/>
</MenuBarItem>
</ContentPage.MenuBarItems>If instead of the attached property you want to express the accelerator in C#, then you can you can write:
MenuItem.SetAccelerator(AddProductMenu, Accelerator.FromString("ctrl+a"));Now when those keys are triggered, the AddProductCommand fires just as if a user had tapped or clicked the menu item. See the Accelerator.FromString method for a list of supported modifiers.
What’s fixed and improved in .NET MAUI
The main focus of the release is on bug fixes and quality improvements. For a complete set of changes, review the 8.0.0-preview.7.8842 release notes. Here are the highlights:
-
Memory Leak Resolutions:
-
Enhanced UI Control Functionality:
- UI controls like Border, WebView, and Entry received updates to their behavior, performance, and customization options on different platforms (iOS, Android, Windows). These enhancements contribute to a more user-friendly and feature-rich experience. #14740, #15881, #15585, #14846, #16215, #15458, #16270
-
Platform-Specific Improvements:
-
Bug Fixes and Refinements:
- Several bugs, ranging from appearance issues (Shell TabBar) to functionality (SelectedItemChanged in ListView), were resolved across different platforms. These fixes contribute to a more polished and error-free application. #16128, #16241, #16275, #14663, #16057, #16116, #16174, #16248, #15099, #15459
-
Input and Interaction Enhancements:
Additional release notes:
How to update
Visual Studio 2022 on Windows now includes .NET 8 previews and the .NET MAUI preview workload. Download the latest preview version (17.8 Preview 1), select the .NET Multi-platform App UI workload, and then check the optional component “.NET MAUI (.NET 8 Preview)”.
There is a known issue on Mac building for Apple platforms when you have both .NET 8 Preview 6 and 7 installed. Please review the known issues for details and steps to resolve.
If you are on macOS, you can now develop using Visual Studio for Mac after enabling the preview feature for .NET 8 in Preferences and installing .NET 8 Preview 7 from the installer.
Download the .NET 8 Preview 7 installer, and then install .NET MAUI from the command line:
dotnet workload install mauiWhat’s Next
We are preparing to introduce Xcode 15 support in the next .NET 8 release for the new versions of iOS, iPadOS, macOS, Mac Catalyst, tvOS, and CarPlay. From that point forward .NET 8 will use Xcode 15 which we anticipate to be the stable Xcode at the time .NET 8 ships in November.
Developer tip: I recommend managing your Xcode versions by explicitly downloading and selecting versions from the Apple developer portal, rather than relying on the App Store which may auto-update and break your compatibility. When maintaining side-by-side versions of Xcode you may want to use something like Xcodes.app.
Feedback Welcome
We appreciate your feedback and contributions to .NET MAUI. You can report issues, suggest features, or submit pull requests on our GitHub repository. You can also join our Discord server.
Thank you for your support and happy coding!
Light
Dark
43 comments
cannot wait to find out how the new preview messes up my layout again. Grid, one of the most basic Layout classes is broken for months now
What issue are you tracking for Grid?
Seriously you should really start doing customary quality control.
I can totally second what @stefan is saying about every release fixing two issues and introducing two bugs which worked previously, we are stuck on 7.0.58 therefore.
One can most of the times see, which platform your Maui dev used, for developing the control. Because this is the platform where it’s the least broken. Big fun for all the people which really develop one app for three platforms.
Also, everyone I know gave up on reporting bugs on GitHub for maui, because they get not fixed for years, or are immediately closed, because your Maui dev cannot reproduce it with it‘s 3 lines demo app. Or say it belongs into vs feedback, like my ticket with maui symbols. (maui dev didn‘t even read it, simply closed it as a VS issue, I needed to open a second ticket for your people actually read the first one). It‘s 10 month old now, and every Maui user will know if the issue was fixed. Of course not, it’s not in the backlog and this for an easy fix which only involves creating your nugets the way they are supposed to be in the first place. FTR, I’m talking of this issue: https://github.com/dotnet/maui/issues/10654
I guarantee you, the day a MS employee starts creating a real world app with maui, maui will have the same future as UWP and will get canceled, cause it‘s so severally flawed and it‘s management is too stubborn to see their mistakes, that it‘s impossible to reform it.
The future used to be so promising. Now, I’m adopting a Dr. Strangelove perspective in the most literal sense; how I learned to stop worrying and love the Apple, has made life much happier of late. It’s not that things are easier, they’re harder in SwiftUI, it’s not that the tech is better, the Xcode IDE is a couple generations behind Visual Studio, but the destructive force of the Apple eco system and Microsoft’s total neglect might as well be nuclear in scope as it will play out for all things Microsoft. Microsoft has forced this longtime devotee to give up. WinUI, UWP, Xamarin, WPF, Silverlight and now MAUI. All dead. It’s become a relentless onslaught of failure. I’m glad Microsoft at least has the gaul to allow comments like this in. Management needs to be forced to read comments such as this aloud in front of Satya. How do you manage to scare away a die hard loyalist that has promoted the company for almost 35 years, sometimes at great personal cost? Total neglect.
https://github.com/dotnet/maui/issues?q=label%3Alayout-grid
the team would know these issues if a real world app testing app based on MAUI would exist or if some teams inside Microsoft would actually use MAUI (native – not Blazor)
a Hello World or a ToDo app from time to time is just not enough to prove that MAUI is actually production ready.
Also the MAUI project seems to be completely miss managed, there are 4 or even more PMs for a engineering team of <10. And on GitHub (issues or discussions) and Discord, where the community is – only the engineers are active. 1 blog post a month for 4PMs?! That money would be better spent in engineering talent!
I totally agree with you. Hire more engineers, fire the unnecessary and incompetent PMs.
Is there a way to let Satya Nadella know about this? So that he knows that MAUI desperately needs better management.
cannot wait to see the MVU pattern (Comet) to be officially supported.
Just wish MAUI goes well, sincerely.
After updating my .net maui project to preview 7, I’ve got this error “Unable to cast object of type ‘Microsoft.Maui.Controls.MenuFlyout’ to type ‘Microsoft.Maui.Controls.VisualElement”. Is there a solution?
Can you log an issue here https://github.com/dotnet/maui ? What platform are you seeing this one? I did a basic test with Context Menus and they are working for me ok here so I’m curious to see what’s different for your scenario.
StackLayout alintiList = new StackLayout() { Background = Colors.Ivory, VerticalOptions = LayoutOptions.Fill };
/////
MenuFlyout mfly = new MenuFlyout();
MenuFlyoutItem menitYuklemEkle = new MenuFlyoutItem() { Text = “Eylem İfadesi Ekle” };//Colors.DarkTurquoise
menitYuklemEkle.Clicked += MenitYuklemEkle_Clicked;
mfly.Add(menitYuklemEkle);
FlyoutBase.SetContextFlyout(alintiList, mfly);
I’m sorry but you’ve finally managed to break me. I don’t know how else to express it.
The last few months we were constantly catching up with regressions in the .Net 7 Service Releases. There were just so many of them…
The most infamous one being the constantly changing GridLayout and its behaviour of Column-/RowDefinitions that contain “auto” and or ““.
That one finally (After we switched our workarounds maybe 4 times…? I’ve lost track) seems to stick, but now we’re facing issues where we are left with no workarounds and bugfixes that are only ported to .Net 8.
Resulting in the precarious situation that we’re still migrating our Xamarin app to .Net 7 and migrating *that codebase simultanously to .Net 8… with limited people…
Now we can choose which hill we want to die upon: Choose .Net 7 and hope our annoying bugs won’t hinder us too much? Or go full .Net 8 and hope the new outstanding bugs will be fixed in time?
I noticed you like to ask in the comments for bugs/issues holding developers back, but rarely ever answer when they’ve presented valid issues that can’t be answered right away. Would still be great to hear back something like “We acknowledged your problem and it will be fixed in the SR in 2 weeks”. Otherwise it feels like shouting into the void :/
Oh well, I never learn anyway so I’ll give it a shot: #16015, #14931 (Those 2 are especially painful for us), #13570, #8803, #15533
The last one is pretty annoying since it can’t be reliably reproduced. A situation that seems to describe half of the MAUI bugs. Sometimes it works, sometimes it doesn’t. Good luck on creating a reproduction project for that.
On the other hand it is essential to provide a reproduction project, otherwise the git bots will shut down any issue with “s/needs-repro” or “s/needs-info” faster than I can plead for help.
Added bonus: We also experience bugs/crashes sometimes, but only in Release mode. Try debugging that, let alone construct a reproduction project…
I mean: I have every respect for the team. I can only imagine how hard it must be to support something this complex across the basic target platforms.
I just think Microsoft should come clean: This is not the “production ready” UI Framework across Desktop, Phone, Tablet, etc., at least not for anything more complex than a ToDo app. Even if the marketing department says so.
A statement like that could also convince upper management to rethink their investment. Otherwise the conversation would be “Why do you say MAUI is ill-fated for us? It’s the ‘production-ready’ framework by Microsoft. Clearly you, the developer, must be incompetent if it doesn’t work.” 🙁
Even outsiders can recognize that the team is understaffed for the task. Imo the resources could be better spent at something less complex like Maui-/Blazor-hybrid and hopefully that could succeed.
I know about the customer story with Irth but you never see any source code (of course, I know) and it makes me wonder: Did they throw a ton of 3rd party controls, custom handlers, developers, consultants, money etc. at it?
‘Cause that’s what’s needed imo to make any non-trivial app work in MAUI. And if you don’t have that you shouldn’t even bother trying.
.Net 8 so far hasn’t changed my mind about that.
I was once trying to get into the MAUI codebase and contribute something. Visual Studio failed to even compile the solution with very cryptic error messages. I got help, invested lots of time, finally managed to get it compiling and beginning to understand how it’s working together.
Fast forward two weeks later, I pull the latest main and the story begins anew with fresh,cryptic errors that I can’t fathom.
Hats off to anyone who can contribute to MAUI. I decided for myself that I’m probably more productive finding workarounds for framework bugs than trying to get my head around the framework’s source code, as frustrating as that is.
Very good read. (sad tho)
TLDR: It’s not production ready, and propably won’t be for 3-4 more years (optimistic), possibly even more.
You want something easy and stable to develop in. This isn’t it yet (obviously). And I would fear that by the time it will be usable, it will have no traction or relevance anymore.
But I sure do hope for c# unified UI for all major platforms. Maybe I get one in my lifetime, but I highly doubt it. I want Microsoft to succeed with this,.. i really do, but I fear that is just wishfull thinking. If microsoft was really commited, they would have released the new microsoft teams on the MAUI. But that is not possible is it ? – because it’s not ready at all.
Not only the state of MAUI is not “production ready”, but I would argue that GA was also a mistake, at least in presentation. I would deeply agree with ALPHA suffix behind every MAUI version.
Imagine falling for the marketing and actually investing trying to use this thing in production. You just don’t do that. The cost of opportunity here is so high that it is not viable at all considering the alternatives. (Mature different development stacks that have next to 0 of this hassle.)
Differnt team, same story~.
We did want to contribute PRs instead of just Issues as well, but the compiling process is painful.
There are documents, but it’s out dated.
Same here. With each release we must decide if the bugs in the old or the new release are more critical and if we should update or not.
The problem is that the “service releases” are no service release but include many new features and refactorings. And the updates get released too early without enough testing. New features and big refactorings need a preview release to get more feedback. That basic things like grids are completely broken in a service release is inacceptable. And then it took 2 months to release a fix for it. And we are still facing some grid rendering issues in 7.0.92 and it seems now we have to wait until November or switch to the .NET 8 preview.
I understand that you want to ship new features and improvements as soon as possible and that this is the reason the service releases are more than just service releases. But this is only necessary because MAUI is not yet (fully) ready. It’s sad that you can’t acknowledge this.
I really hope it gets better with .NET 8
I so understand, I feel the same way myself. After months of fighting with Maui to get on Windows and Android I spend half my time ‘fixing’ what was working before. I wonder if all the hard work has been for nothing sometimes with Maui and wish I had never heard of it and could have just kept the original fully working Xamarin applications.
MAUI should be discontinued. It’s an acceptable concept which has been failed by poor management, poor talent, poor sense of responsibility.
Working with MAUI cost me 4 months of wasted development time. I have since switched to Flutter and am happy with that choice. I was able to rewrite my app in Flutter in 6 weeks, which in MAUI took me 4 months and was still buggy and slow.
Just use AvaloniaUI, people. It’s so much more refined and stable !!
I’m a little confused with the new releases of Visual Studio 17.7.0 and 17.8 Preview 1.
The recent prerelease versions of Visual Studio 17.7 supported the .NET 8 preview, but the GA release of 17.7 does not. So now to use .NET 8 preview, we have to bump up to a higher, less tested version of Visual Studio?
I just want to make sure I’ve got that right.
Will the GA version of Visual Studio (17.7) support .NET 8 really soon (like in the release candidate phase starting next month), or is that not going to happen until the GA release of .NET 8 in November?
I’m just trying to time moving my code over from old to new balancing disruption level with getting to the new bug fixes as quickly as possible. If I can move over next month without having to change to an early prerelease of Visual Studio that might be a good choice. Otherwise, it sounds like the best option is just go with the VS 17.8 prerelease 1 and get the bug fixes now.
Yes, Visual Studio GA releases won’t go out with preview versions of .NET, so it is pulled from that release and continues in the next preview version. When .NET 8 is GA in November, it’ll be in the corresponding GA version of Visual Studio.
Hi David
Unfortunately MAUI Preview 7 has dependencies to not released .net 8 assemblies which results in NU1603 warnings which you need to silence if you have warnings as errors. It is really hard with MAUI forcing to use previews but every preview has new problems.
error NU1603: Warning As Error
Microsoft.Maui.Core 8.0.0-preview.7.8842 depends on Microsoft.Extensions.DependencyInjection (>= 8.0.0-preview.7.2336
4.3) but Microsoft.Extensions.DependencyInjection 8.0.0-preview.7.23364.3 was not found. An approximate best match of M
icrosoft.Extensions.DependencyInjection 8.0.0-preview.7.23375.6 was resolved.
error NU1603: Warning As Error
Microsoft.Maui.Controls.Core 8.0.0-preview.7.8842 depends on Microsoft.Extensions.Logging (>= 8.0.0-preview.7.23364.3
) but Microsoft.Extensions.Logging 8.0.0-preview.7.23364.3 was not found. An approximate best match of Microsoft.Extens
ions.Logging 8.0.0-preview.7.23375.6 was resolved.
This is a result of the build process and timing. We are discussing solutions so you don’t run into this warning. To address it now, explicitly install the shipped version of those packages.
Could you please clarify?
For example for this warning:
warning NU1603: Microsoft.Maui.Controls.Compatibility 8.0.0-preview.7.8842 depends on Microsoft.Extensions.Logging.Abstractions (>= 8.0.0-preview.7.23364.3) but Microsoft.Extensions.Logging.Abstractions 8.0.0-preview.7.23364.3 was not found. An approximate best match of Microsoft.Extensions.Logging.Abstractions 8.0.0-preview.7.23375.6 was resolved.
For “Microsoft.Extensions.Logging.Abstractions” the version “8.0.0-preview.7.23364.3” does not even exist in the NuGet repository. So what am I supposed to explicitly install?
Hi David,
I just started migrating a small XF project to MAUI .NET 8 Preview 6 (after a failure with migration in August last year I decided to wait for some improvements).
All was working nice in iOS and Android emulators and then I deployed to Android devices.
Guess what? Basic ListView doesn’t work. It displays rows as it wants plus some other random UI bugs.
How can I work with that???
I don’t expect the Preview 7 to be much better.
Honestly I don’t know where to go from here if we have to migrate few complex XF projects before May next year?!
(Maybe MAUI Hybrid works better but I wanted to migrate our XAML code without full UI rewrite)
Sorry you’re hitting those issues. Shoot us an email with your github issues and let us help you out. maui-upgrades@microsoft.com
this comment has been deleted.
So, a stupid question, but why is it called
Accelerator=and not justShortcut=or something? Is it intentionally more generic to be used for more in the future?Not stupid at all, I’ve asked it many times before. It comes from the naming from the desktop platform frameworks. The current naming and implementation came from the Xamarin.Forms macOS backend contribution.
https://learn.microsoft.com/en-us/windows/apps/design/input/keyboard-accelerators
We are entertaining aligning with this naming more closely, adding Keyboard to the name.
Microsoft’s terminology is all over the place. Windows and Win32 use term “accelerators” but then define those through “shortcuts”. In VS and Windows Forms parts of the docs shortcuts are referred to as “shortcuts” (e.g., here, here or here). And WPF uses “input gestures”….
Apple uses “shortcuts” (e.g. here). So does Ubuntu (e.g., here).
Will appcenter (a microsoft product used by tons of existing xamarin developers) ever support building/deploying MAUI apps?
Re
https://github.com/microsoft/appcenter/issues/2360 and
https://github.com/dotnet/maui/discussions/3333
We recommend Azure pipelines and GitHub for .NET MAUI apps. Any roadmap information about App Center would come from that product team.
Although I appreciate the reply, the only reason I’m posting here is because we have gotten complete silence from the App Center team for 1.5+ years at this point. See the github discussions I linked in my first comment. We can’t even get the courtesy of “we won’t support MAUI builds, use x, y and z instead.”
Although I am in the process of switching to github actions for my company’s app, I am only doing it as a result of absolutely no updates about appcenter. Its unfortunate since it is a Microsoft product that is used by many existing Xamarin developers. Dropping support for it makes a lot of developers want to jump ship and switch to flutter or react native, etc.