4 ms·
UWP is not the successor to WPF for a simple reason: it's sandboxed, and comes with a very prescriptive UX platform (no tree-view, hWnd, or FileOpenDialog here,
by DaiPlusPlus 10y ago
UWP is not the successor to WPF for a simple reason: it's sandboxed, and comes with a very prescriptive UX platform (no tree-view, hWnd, or FileOpenDialog here, folks!)
For line-of-business apps it's DOA because ADO.NET is not available. Custom widgets (e.g. for industrial control) are much harder to develop because there's no replacement for GDI. The list goes on. UWP is, and was intended to be, only a platform for "apps" which act as a frontend for externally hosted web-services - not "real software".
What we should be campaigning for is for the XAML "Jupiter" platform within UWP to be made fully available in the pure Win32 world, with no special runtime, sandbox, or artificial restrictions.
- WorldMaker 10y agoYou seem to be under several misconceptions. Yes, it's sandboxed by default, but that isn't the problem you seem to think it is. - It wasn't a good idea even in WPF to use an hWnd directly - There is a full file browser available to UWP apps since Windows 10 - The application design guidelines are much less prescriptive since Windows 10 - There's nothing saying you can't use a tree view, just a warning that most users don't like tree views and tree views are typically not very accessible (to users with disabilities, to users that prefer touch controls, to users that hate navigating useless hierarchies) - DirectX has been the suggested replacement for GDI since WPF launched, UWP just enforces it; UWP XAML even has more and better ways to composite DirectX and XAML layers together - That stated, System.Drawing is higher level than just GDI, and is missing today. This is also an issue faced by .NET Core in general. There are open source System.Drawing replacements available today. .NET Core should have one more directly in .NET Standard 2.0/.NET Core 2.0 soon (and UWP once .NET Native pulls that in) - The "desktop bridge" allows full Win32 processes to bundled with an application - The full jungle of ADO.NET is an issue, but it's the same issue being faced across all of .NET Core: it's expected to get better with .NET Standard 2.0/.NET Core 2.0 soon and the .NET Native that pulls that in - Even "real software" needs sandboxes for security and reliability. That was the complaint with UAC in Vista; that's the same complaint here. Exactly like with UAC the UWP sandbox started (back in the "WinRT days" in Windows 8) from a position of strength and is slowly working to strike a balance for "real software" to run but also be secure and easy to install/uninstall From a lot of the .NET side of complaints, the "artificial restrictions" are primarily the transition to .NET Core. Yes, it's a sometimes painful transition for legacy WPF applications, but it's a lot better than the WPF/Silverlight transition and it's a transition that will continue to get better as .NET Core grows. A lot of the complaints about .NET Core in general are going to go away with .NET Standard 2.0/.NET Core 2.0, which will converge a lot more of the "classic .NET Framework" into/on top of .NET Core.
- maxxxxx 10y agoSeems the best approach is to wait and see how .NET Core 2 shapes up and also to wait until your company actually uses Windows 10. By that time MS will probably have come up with something new anyway :-)
- WorldMaker 10y agoOr use the Desktop Bridge today with your existing WPF app. Add UWP XAML screens and Windows 10 features as you see fit. As you find you are able to do more in UWP directly and grow more Windows 10 users, cut more functionality over to the UWP sections of your app.