Replies: 82 comments
-
|
Agree 100%! Thanks for taking the time to write this up! I really hope Microsoft considers this, and give us a clear roadmap and strategy for us to go forward with WinUI 3. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the write-up @robloo I need mapcontrol and inkcanvas. Both missing without any timeline. |
Beta Was this translation helpful? Give feedback.
-
|
An important use-case of WinUI that the team should facilitate before general availability is moving a project from UWP -> Desktop. For instance, what if an organization started out by investing in UWP for the latest XAML UI experience, but now that this is ubiquitous with WinUI WinUI desktop and even Project Reunion, can they easily move their desktop investments from UWP to WinUI Desktop? For example: before WinUI existed, I imagine developers chose UWP because they mistakenly anticipated the addition of APIs for better integration with the Windows Shell. Developers recently learned that the goal isn't to replicate every last Win32 API in WinRT, but they may need some of those APIs for their desktop-specific project. A WinUI Desktop project is ideal for deep desktop integration like this. Guidance should be published for this area. |
Beta Was this translation helpful? Give feedback.
-
|
This roadmap Clearly shows what the priorities are. Apparently the near future(2-3 Years) is Win32 with a subset of UWP/WinUI 2.X called WinUI 3. And in the far future(3 -5 years) maybe we get .Net 5 on UWP and eventually they add more of the WinUI 2.X features to WinUI 3.X. It looks like they HATE MapControl!!! Does this strategy make sense? Are developers clamoring for a subset of WinUI 2.X on Win32? I don't see a clear path from UWP to Win32/WinUI 3.X for several years. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I think we are all aware of the roadmap. You're absolutely right that its quite problematic from a UWP standpoint. Thinking about this some more, I guess it only makes sense if you are coming over from old C++ frameworks like MFC. Being overly optimistic, maybe Microsoft is internally making WinUI 3 to first modernize Windows shell and apps themselves with XAML tech. In that context things would make some sense. However, I kind-of doubt Microsoft is doing that much internally even with Windows 10X. |
Beta Was this translation helpful? Give feedback.
-
Which is exactly why betting on classical WPF and Win32 seems the more sane thing to do, unless Microsoft really adresses these issues. So far we have only gotten promises that things will get better, and I don't know why Windows 10X even keeps poping up, there is no device available with it, the Win32 sandbox was dropped from the design and eventually not even the hardware itself is going to happen (the MSDN related pages were removed). We just need to check the ongoing increase of Reunion issues to see how many years it will take, if it ever makes it. Also the unwilligness to address issues like not exposing COM libraries as UWP components, and then forcing us to use C++/WinRT instead of C++/CX to write our own bindings, was the final drop. |
Beta Was this translation helpful? Give feedback.
-
Will it work on all Windows powered platform? I guess the answer is NO. Which is the start of another set of issues for future. |
Beta Was this translation helpful? Give feedback.
-
|
A WPF/.net5 solution should actually run on all windows platforms -- arm included -- except for XBOX and maybe Hololens. That's a very reasonable tradeoff for the vast majority of apps. WPF is also known to work on macOS and Linux with some not impossible or impractical techniques. I tend to agree that I wish I stayed with WPF with a plan to move to WinUI in a year or so. However, the commitment in time and money was done years ago to move to UWP expecting that it was the future and new functionality would only be added there. |
Beta Was this translation helpful? Give feedback.
-
Then what is the use of WinUI 3 Desktop App? The compatibility you are talking about is here Quoting from the above link Reason for changeIt's assumed that most users don't want a console window to open when a WPF or Windows Forms app is executed. In addition, now that these application types use the .NET SDK instead of the Windows Desktop SDK, the correct default will be set. Further, when support for targeting iOS and Android is added, it will be easier to multi-target between multiple platforms if they all use the same output type. |
Beta Was this translation helpful? Give feedback.
-
There are still many reasons to update. For example,, Wpf was never designed for touch screens or mobile-sized devices and their input methods. Wpf doesnt have latest controls especially for Webview and the like. Uwp also has far better performance in some scenarios.
I think that's bad wording. WPF is likely never getting cross platform support from Microsoft. They've been very clear on that. However, the community has got it working. They are talking about .net6 I think Which won't include a UI layer except for Maui (which is terribly inferior). Here is what I was talking about for cross-platform WPF. A lot of recent developments were made after WPF was open sourced. https://ccifra.github.io/PortingWPFAppsToLinux/Overview.html |
Beta Was this translation helpful? Give feedback.
-
There will be absolutely no reason for WinUI3 Desktop app for not being able to run on other windows powered platforms once AppContainer sandbox comes to win32 apps, win32 apps medium IL processes will need to be brokered with the system with the help of runtime broker so that it works for the AppContainer sanbox apps. AppContainer solves privacy+security issues. UWP's App LifeCycle is coming to win32 apps , x86 apps are no longer hog battery juice when it is compiled for ARM64 on arm64 devices.. Sorry, I see no reason to update a Desktop-Only app when it just works for current users, and and similarly see no reason to develop a windows app if it doesn't work on every windows powered platfoms. WinRT API are so buggy and I don't have any trust in UWP. Win32 apps going universal will be ideal in 2020 both for Windows's future relevancy and for Microsoft. so that existing windows apps can update and opt into other windows powered platforms easily like UWP. |
Beta Was this translation helpful? Give feedback.
-
WinUI 3 will bring you modern UI that will scale nicely for high DPIs, as well as those controls updating outside of OS updates. Project Reunion will bring modern APIs and wrappers around older APIs. Plus both of these will be open sourced. As legacy Windows versions are left behind, future investment and feature work will target Reunion and WinUI. |
Beta Was this translation helpful? Give feedback.
-
That was the UWP promise yet here we are. One of my main points was a lack of confidence in Microsofts ability to follow through with WinUI no matter how good the intentions are. |
Beta Was this translation helpful? Give feedback.
-
Many devs continue to nurture their Win32 codebases, and didn't or couldn't move to UWP and Sandboxed App lifecycles. So Microsoft is using Reunion to allow Win32 apps to access modern APIs, so they don't get left behind. And WinUI is bringing XAML UI out of the UWP sandbox, for existing Win32 apps to adopt and use. |
Beta Was this translation helpful? Give feedback.
-
|
@mdtauk Of course I'm well aware of that. From a UWP standpoint we are in a very poor position though. There havnt been updates in years and now I can't easily move to WinUI 3 either. Microsoft is now catering more to those win32 devs than those that followed microsofts recommendations a few years ago. |
Beta Was this translation helpful? Give feedback.
-
|
Winforms (2 steps forward) -> WPF (3 steps forward) -> Silverlight (2 steps back) -> UWP on Win8 (1 step forward, 1/2 step back) -> Xamarin (3 steps sideways) -> UWP on Win10 (2 steps forward) -> WinUI (1 step forward, 3 steps back) Microsoft's published roadmaps regarding WinUI have turned into an odd form of fiction. Bottom line, WPF, UWP and Xamarin are still your best choices. WinUI may eventually catch up to where UWP is today. It's more likely it will be deprecated before that happens given recent history with Microsoft technologies. And for those Microsoft staffers that might remark we should be more positive and supportive ... please say Silveright three times in a row and accept that: “No matter how dreary and gray our homes are, we people of flesh and blood would rather live there than in any other country, be it ever so beautiful. There is no place like home.” ― L. Frank Baum, The Wonderful Wizard of Oz Welcome home Microsoft. |
Beta Was this translation helpful? Give feedback.
-
Yes it is very disappointing. By the way you forgot to mention it's also much slower and memory hungry. I don't think 16GB will not be enough anymore for a windows computer. Unfortunately macOS is in the same condition. The terrible new state of modern agile development with fixed tight marketing driven timelines. The Win11 debacle with Ryzan CPUs shows its everywhere. May God (pick your favorite) help us that neither Apple nor Microsoft ever enter the world of medical devices. |
Beta Was this translation helpful? Give feedback.
-
Win32 API -> MFC -> WinUI3 is so much less change. You just picked the wrong language, finally i can say this once as a C++ programmer 😂 |
Beta Was this translation helpful? Give feedback.
-
|
@llothar , I did my fair share of Win32/MFC work. The sense of control and stability is derived from the fact that you had to do virtually everything yourself. Meta level work is supposed to be better. |
Beta Was this translation helpful? Give feedback.
-
|
@llothar I believe that the separated development experience between UWP and Win32 had been one of the most criticized issues in Windows development, so from my perspective, the migration is really a step forward. I do believe that you can do everything that of WinUI capabilities in Win32/MFC, but the problem is not what you can do. Things like the event system and the UI design and the overall management of the app are absent in the traditional Win32/MFC development and they are pretty vital to the modernization of the app. So unless you'd like to implement them by yourself, I think the best option is to embrace modernization. |
Beta Was this translation helpful? Give feedback.
-
|
There should be a focus on closing this gap ASAP, before pushing forward. The UWP door is closing, and the hurt will persist for as long as WinAppSDK doesn't cover EVERY aspect of UWP that enticed those developers to begin with. Privacy, Permissions, and Trust of the installation is going to be the biggest loss with WinAppSDK as it is now. Mobile platforms are doing well as both Google and Apple are chasing privacy and security. Permissions is where UWP did well from its core, and unless WinAppSDK implements that "gatekeeping" into its core, we will be stuck with Win32's security risks, and that will affect users going forward. Also Xbox... Xbox development will be stuck with PWAs and full on games engines - without a clean API and UI platform to design to. |
Beta Was this translation helpful? Give feedback.
-
That being said, I do agree that the lacking of functionalities in WinUI should be fixed ASAP, It seems that Microsoft wants to get rid of UWP so urgently, but as its replacement, the current WinUI 3 can hardly be recognized as a production-ready framework |
Beta Was this translation helpful? Give feedback.
-
All this security risks are very important features for other people. The serious restrictions of UWP are terrible and one of the main failures. You can't create a productive business environment with it. It's also why macOS and iOS are still maintained differently even when they have the same hardware now. I'm sorry but i really would love to even get my OLE2 back so i could show a office document directly in my App again. I fear this times are over but not for the benefit of the user. Security can be well done on administration level and when you don't have a business model that lives on users installing as many apps as possible and make 30% of it. I would love to see that we have more security virtual machines under a single Desktop GUI, so you can run your professional apps in one and games in the other and for new trial software a run once testing vm. But please never ever again force us into this tight restrictions and individual App separation we have on Android, iOS and UWP. |
Beta Was this translation helpful? Give feedback.
-
@llothar Halleluia 😁I don't have a problem with implementing restrictions, but they way they're implemented in WinRT is simply beyond words. In sweet MS fashion, no one asked us what we'd like, they just pushed it on us, nobody liked it, but they kept pushing and saying it's the "right" way. Every bad thing related to UWP/WinRT stems from this point -- the restrictions/file system. And to see how bad they are, just look at how long it's taking MS to port them away... |
Beta Was this translation helpful? Give feedback.
-
@llothar Only If you happen to enjoy doing ATL/WRL without any kind of VS support, just like back in 2000. It is incredible how after four years C++/WinRT is still a shadow of C++/CX tooling, and nowhere as productive than MFC ever was. |
Beta Was this translation helpful? Give feedback.
-
@robloo - I know it has been 1.5 years since this update. But just wanted to check if at this point you aware of any tooling support for WPF to WinUI3 migration? We have a huge WPF (MVVM) code base where we use lots of standard WPF controls as well as many custom-built controls for which we have the source code, but also use several 3rd party controls (e.g Infragistics). We would like to upgrade to WinUI3, however the lack of tooling seems like this will be a lot of work and not sure if we get stuck anywhere in the middle due to some functionality not being available in WinUI3, that will be a bummer! |
Beta Was this translation helpful? Give feedback.
-
|
@santhoshk Plenty of stuff is still missing, MAUI team had to ship a webwidget maps control, because UWP one isn't there, no designer, Native AOT doesn't do GUI code, C++/WinRT is at the level of ATL/WRL, some APIs like widgets are C++ only for now, and so on. Just keep that WPF application going, and port as much as you can into GUI independent libraries. Possibly check Avalonia or Uno as possible migrations. |
Beta Was this translation helpful? Give feedback.
-
|
@santhoshk As stated, most all of that list is still a missing feature in WinUI 3. The WinUI team seems to be getting smaller as well and project Reunion was deprioritized it seems after being well over a year late. Bottom line Microsoft is doing again what they always do with their XAML UI frameworks. I would caution strongly against porting without doing a deep-dive analysis and WPF is still a pretty good option. On my end the UWP code is in maintenance mode and apps are being moved to Avalonia. The situation with Microsoft XAML UI frameworks just isn't a good business case anymore. Concerning tools to migrate -- there absolutely is no automatic migration tool from WPF to UWP/WinUI3. You are going to have a nasty time with it on a large code base as well. That is something we all went through going form WPF -> UWP years ago. Recommend taking a look at a doc of differences I put together: https://github.com/robloo/PublicDocs/blob/master/UWPvsWPF.md. UWP, generally speaking, has even more features than WinUI3 though so it's going to be harder. My recommendation is to stay on WPF unless there is a real technical reason you need to modernize. Then I would take a long look at Avalonia instead (migration from WPF to Avalonia is generally smoother than WPF to UWP/WinUI3 as well). |
Beta Was this translation helpful? Give feedback.
-
|
Commenting to keep this open because Microsoft strategy is still quite poor due to missing features. |
Beta Was this translation helpful? Give feedback.
-
|
Commenting to support this issue. hope Microsoft fix this soon and guide us in migration journey. It's really hard to migrate from wpf to winui as a lot of things have changed. |
Beta Was this translation helpful? Give feedback.
-
Discussion: WinUI 3 Strategy for Existing Developers & Apps
WinUI 3 is a great idea. Decoupling from the OS solves a lot of problems to fix issues without compatibility concerns, ensure apps can ship with the framework they test with, and new features are available earlier - all great. Open sourcing is another huge win as well. However, this great vision is shaping up to be something less. WinUI 3 seems to be making one of the same strategy mistakes as UWP: alienating existing developers and providing a poor migration path for the last version of the tech (UWP).
WinUI 3 right now makes the most sense for developers writing new applications. Existing developers whether they be C#/C++ (F#/VB totally out of luck) or UWP/WPF will face some serious hurdles going forward. So far Microsoft is not directly addressing these hurdles. Concerns are always acknowledged but solutions seem 1-2 years away for many topics. These issues need to be brought to the forefront with Microsoft management and the strategy discussed and then clearly communicated. Otherwise, for both Microsoft and Developers, we are in for a bumpy road ahead.
Some of the hurdles we have with WinUI 3 today are below.
Overall, the big changes Microsoft is taking on are encouraging to see. I know WinUI 3 and Project Reunion are also intended to bring everyone together and really support mix/match of components. However, Microsoft probably bit off more than they can chew again and I don't know when or if that vision will be met. It's more likely that the vision will never be truly realized and instead we are again left with a partially-completed development stack. To mitigate those risks we need a solution for existing developers and apps that allow a clean transition.
Microsoft needs to:
If Microsoft doesn't address these issues I know companies, including my own, are going to seriously reconsider Microsoft tech overall. We can't keep repeating the same mistakes every few years. UWP is basically the final straw and better tech exists like ASP.NET/Blazor and React Native.
Related Links & Discussions
Beta Was this translation helpful? Give feedback.
All reactions