At Build 2018, I outlined our approach to helping you be more productive when developing apps, including the introduction of .NET Core 3.0. We also started decoupling many parts of the Windows development platform, so you can adopt technologies incrementally. Today at Microsoft Connect(); 2018 Conference we shared the next steps – specifically to support innovations in UI:
- .NET Core 3.0 Preview 1 adds support for building client apps using Windows Presentation Foundation (WPF), Windows Forms, and XAML Islands.
- WPF, Windows Forms, and Windows UI XAML Library (WinUI) are now open source, so you can create experiences with the freedom you want.
I want to be excited by the thought of WPF being ported to Linux, but the only UI framework that excites me these days is Flutter.
WPF is what you would get if you asked 100 Windows developers what they want from a UI framework and ignore the 1 guy who asks for Linux support.
It is an amazing bloated monstrosity.
It’s funny because I feel like Flutter is the Android equivalent of WPF.
So which of these tools is used to build Metro applications on Windows? I mean, Windows Store/universal apps… whatever Microsoft is calling them this week?
It is called WinUI, which builts common controls on top of UWP, compatible with Window 10 since Anniversary edition.
Open-sourcing windows Forms and WPF, I guess Microsoft expects the community will port those to GTK+, Qt, or other cross-platform UI backend.
And with that in place, porting a lot of Windows-centric desktop applications to other .NET Core platforms will be easier.
Very nice move, Microsoft!
Windows Forms is not portable, it is a .NET wrapper around the win32 API. You would have to rewrite the whole library from scratch or pray that Wine is adequate replacement for Win32.
This code dump would be of no use to the abandoned mono Win Forms project. That project was a from scratch re-implementation.
WPF is a lot more interesting.
You cant emulate WPF with Gtk or QT widgets, there is a huge gap in functionality.
The biggest challenge in porting WPF would be porting it’s 2d drawing code from DirectX to something portable.
WPF draws it’s own widgets and their code is written in in C#, so you should need to make many changes to the higher level portions of the library.
Mono has had a Winforms library backed on Gtk for quite a while now.
Doing some weird tweaks, this thing could call Wine Win32 APIs; dunno if useful, but really interesting.
If you use Wine, that’s essentially exactly what’s happening.
All that’s stopping someone from targeting Wine is, well, testing their app with Wine. Most simple WinForms applications run without a hiccup.
Sadly, Microsoft said they won’t be accepting contributions that bring WPF to other platforms, so any porting will have to happen separate from the main development
They’re not interested in porting WPF to Linux, they said as much in the comments section of the article. If you want to develop a cross-plaftorm app with .NET, Microsoft’s answer is and continues to be Xamarin Forms (which already supports Linux in its preview release version via its Gtk# backend).
Of course the community could jump onboard with this, but honestly, WPF isn’t that great from a developer ease-of-use perspective. IMHO, YMMV. Of course there are a lot of WPF applications already out there and potentially in need of maintenance, especially line-of-business/internal applications, but I imagine even then most of the customers are Windows-based. Assuming some big customers were to migrate all their workstations to Linux, I could imagine a company like Telerik putting effort into a port; otherwise I am skeptical that the interest is there.
See my top-level comment below for more details of where I think MS is going with this move.
http://www.osnews.com/permalink?666067
Edited 2018-12-06 00:11 UTC
I can’t help but feel this is MS lame “solution” to the the way 1809 broke so many legacy Apps. Rather than fix the OS they’ve made some of the very problem libraries open source.
That doesn’t mean people will get functionality back, it just means developers who want to sell upgrades get access to the libraries and MS as the OS provider no longer has to fix the problems they have created.
It feels like MS saying “not my problem”, no wonder so many people are vowing to move platforms!
I suppose MS cannot win, if they preserve legacy the developers become loud voices of complaint. If they break legacy the users are unhappy. Are developers the end user client, it’s the old argument?
Edited 2018-12-05 00:49 UTC
Making .NET open source and the roadmap that had 3.0 with WPF and WinForms support coming out before the end of 18 was in place and publicized LONG before October. But whatever.
How should I read that statement, long before they killed support for legacy apps in October they knew they were never going to fix it!
Is that suppose to be better?
Is that how to retain users?
Microsoft has been planning on, and working towards, open sourcing .NET since 2014. The 3.0 release of .NET Core w/ WinForms and WPF support has been on the roadmap for years (literally). I converted a Winforms project from VS 2015 w/ .NET Framework 4.5x to VS Code with .NET Core 3.0. It took all of 5 minutes. Whatever doom and gloom you are claiming regarding Win 10 1809 breaking ‘legacy apps’ without listing specifics really has no bearing on any of this – They haven’t abandoned .NET Framework 4.5x. Apps built against that will continue to work just fine. And, if and when they stop distributing Win 10 .NET Framework runtimes (if ever) those programs can be rebuilt against .NET Core very easily. Given that Microsoft goes to ridiculous lengths to ensure compatibility with programs that are decades old, I doubt you’ll ever see a program written against .NET Framweork fail to work on Window.
.NET Core does nothing to ‘legacy apps’ for good or ill. It’s a new SDK and runtime libraries that are permissively licensed and can be used on many platforms. Any correlation you see between the preview release of .NET Core 3.0 and ‘legacy apps’ being unstable in 1809 does not imply a causal relationship between those two things.
Edited 2018-12-06 04:44 UTC
I’m not qualified enough to debate this with you, I’m discussing what is being reported as the failure cause for various legacy apps as discussed on support forums including MS own support forums. The problem as I understand isn’t to do with .Net itself but how the OS handles applications built using older versions of WinForms. There are even several programs you can freely install to prove this case, because the programs support multiple themes built using various versions for WinForms and they crash or behave oddly only when a theme derived from an earlier version is loaded.
btw, I believe legacy versions of MS own software from as recently as 2010 which will suffer this same fate so there is no doubt MS know about the problem. That means this wasn’t unexpected, it was a choice!
My personal issue with this is that the poor backward compatibility of many extremely expensive programs means I have to keep a library of legacy software running to ensure I can diagnose, debug and calibrate hardware(electronics) developed on older platforms. It was a huge plus for us was that when Win 10 Pro came out we could migrate to a common modern platform that supported the legacy hardware and software perfectly. Something Win 8 Pro failed dismally at doing, prior we had been forced to stay on Win 7 or even Win XP in some cases before Win 10 Pro solved all the problems.
Now that compatibility is gone I’ll have to go backwards to Win 7, I’m hoping like hell I can avoid Win XP, and MS want to start charging me fees just to keep Win 7 running a bit longer, just to do what we done for more than a decade.
When you make claims like “1809 breaks applications built using older versions of WinForms”, “poor backward compatibility of many extremely expensive programs” and even “Now that compatibility is gone…” you really should provide some more information or sources because this is not one of the problems that 1809 is well known for.
Without such sources it sounds like you are whining
This was the only thing that I could find: A program unknown to me from a company that I do know that had an issue with a theme that provided both a workaround (switch theme) and a patch that both solved the issue. Seems more like a problem in the code from that company than a general issue in 1809.
https://designspark.zendesk.com/hc/en-us/articles/360005362153
Firstly, sorry if I’ve come across as whinny, but then perhaps this forum is suitable for that.
OK, I think I’ve failed to make a core point I’m making clearly, because for many users updated software already exists that resolve the issues.
But for some industries and applications that update is not an option, primarily because compatibility of an upgrade is rarely 100% backwards compatible. In the cases I’m discussing the issue is we have to keep the legacy versions running in addition to having the new platforms running, because backward compatibility is generally only close enough which for us is not good enough.
What is not good enough? In another thread I had a poster tell me it’s bad luck, just upgrade the hardware or software. Despite the costs involved I also mentioned the case of defibrillators, because some legacy software used to calibrate defibrillator implants was something broken by 1809. And while we as a manufacturer can air gap and preserve legacy platforms for this purpose, we are not in 100% control of what happens in the field. In 1809 a floating point error appeared which produced a calibration error in writes to FPGA, an order of magnitude error. If someone tries to test and calibrate an older defib using the legacy software on an 1809 platform the device would appear to be correctly calibrated and functioning. However, when it is time to do it’s job it would deliver 1/10th the required stimulus level to correct an episode.
We can’t just cut people open and upgrade the hardware! If someone misses our 1809 alert somebody could die, all it seems so that a game developer can have better smoother experience and a less repetitive and boring job!
Now I expect this error to be corrected shortly, I know it’s on MS radar already, but the wait is nerve racking! What is the real concern is that it appears this was not an accident or oversight, but a deliberate choice to break compatibility that wasn’t broadcast at the time!
Perhaps my perception of events is wrong, perhaps it was just oversight.
Edited 2018-12-07 00:02 UTC
[q]So you are now claiming that Microsoft has broken compatibility on purpose by generating a floating point error.
And you work for an ICD manufacturer that calibrates their devices with legacy software and that your customers do the same on random computers.
And the software is so breakable that a small rounding error causes a 10 times weaker output of the ICD?
But luckily this is all on Microsofts radar and a fix is coming soon.
Please tell me three things:
1) Why is that calibration software so outdated?
2) Where is this malicious bug documented so I can let a friend know they should test their similar devices and software
3) You claimed that many programs were affected by this. Is there a list by Microsoft?
All the problems are alleged to be related to deliberate decisions to drop OS legacy support to enable accelerate development of newer architectures.
We use “outdated libraries” for the very same reason space agencies use “outdated silicon” from the 80s and 90s. They are very very well known. But the calibration problem is related to libraries / drivers for USB based oscilloscopes that have been broken by 1809 without presenting any obvious problem. I found the error by using old analogue hardware to cross check unusual results using the software based systems.
I don’t work for the device manufacturer, they use sensors I develop, I spend most of my time eliminating software with hardware, software is unreliable but a necessity.
Edited 2018-12-08 01:26 UTC
Hm, space agenices use outdated process nodes not so much / only because they are “very very well known”, but because the older/larger ones are intristically more resilient to radiation…
Is there any major application built on Windows Forms or WPF?
Visual Studio, Adobe XD for example.
All major Windows software is a mix of .NET and C++. MFC has been in life support for ages and only a few enterprises make use of Delphi/C++ Builder.
On Windows, Qt tends to be mostly used by FOSS folks.
And then there are few radar blips from less known frameworks like wxWidgets or POCO.
I don’t think POCO counts as a framework. Certainly not one intended to be in the same usage space. It’s more like a Boost competitor.
Autodesk uses QT pretty broadly.
Adobe uses it in a lot of their software, too.
Qt. “QT” is QuickTime.
After reading some of these comments it seems there is a general lack of clarity about why MS seems to have made these moves.
The reason is not to create the next big cross-platform UI toolkit. If you read the comments section of the Microsoft blog article, they explicitly say they have no plans to do this. For WinForms this seems obvious, and for WPF and WinUI also more or less obvious since both depend on a lot of Windows-specific code and would thus need to be substantially rewritten.
There is a cross-platform strategy, however, even for UI – that is, and continues to be, Xamarin Forms. It lets you build apps using generic XAML controls and C#, which are then compiled to produce “native” apps with native controls on X number of platforms. To date this has meant UWP, Android and iOS, but preview versions are already available to support macOS, Linux (via Gtk#), and WPF (not sure why WPF tbh, maybe for migrating existing applications?).
Anyway, that is Microsoft’s cross-platform UI story for “proper” apps. (I say “proper” because they are also investing in supporting web apps, indeed that may be a motivating factor for their move to Chromium. But that’s a story for another day.) With Xamarin they have invested a lot in supporting “native” look and feel on all platforms with a maximum of shared code, and I don’t expect that to change in the near future, since they deem native look and feel to offer the best user experience. Aside from that, there is no reason to believe they would succeed with a new cross-platform toolkit considering that the likes of Java Swing and JavaFX have seen only moderate developer adoption up to now.
The other thing to keep in mind is that MS really wants to push adoption of .NET Core (as opposed to the old, Windows-only .NET Framework). Due to its freedom from legacy, backwards-compatible cruft, MS is implementing the most improvements to the APIs on .NET Core first, and a lot of toolchain improvements are exclusive to .NET Core and can’t be brought to .NET Framework ever. Version 3.0 of .NET Core supports WinForms, WPF and WinUI (UWP), which means finally the holy grail of all .NET applications being able to run on .NET Core will be fulfilled.
So it’s clear MS wants to get its UI toolkits running on .NET Core, and also have them be supported by Xamarin Forms, but did they really need to open-source them to do so? While it may not have been strictly necessary, I think it helps a lot from a licensing and a community perspective (think GitHub issues and contributions from other companies that are invested in .NET). Also, it should make Microsoft’s life easier regarding how to distribute further development resources on these libraries: Just watch and see which have the most active communities, and base it on that.
In summary, this move is good for cross-platform development in that it should increase adoption of .NET Core, and potentially also Xamarin Forms. However, it seems unlikely that MS will offer official support for directly using WinForms, WPF or WinUI to develop for any platform other than Windows.
Edited 2018-12-05 23:57 UTC