I really wish they would figure out of cross platform solution for desktop applications. I know their are libraries out there now, but Microsoft should really help with the effort. Maybe Xamarin.Forms? Idk.
Regardless, I'm working on a way to build Qt/Qmp apps with .NET Core.
There has been active public development on ReactXP [1] for months now. It supposedly works with React-Native and React-Native-[Windows|macos].
Considering the amount of work being done in public on React-Native-Windows [2], it looks like this is turning into one of their (intended or not) version of cross-platform (using web technologies) dev stack.
Windows, Windows Phone and Xbox do not use exactly the same OS, or expected set always present hardware, thus they are by definition not the same platform.
Cross platform does not mean it works in all OS ever written.
I don't get it more and more Windows specific features are creeping into .NET Core. Wasn't there already desktop applications support in regular .NET? Very confusing.
Disclosure: .NET Core team member and blog post author.
Windows-specific features are not really "creeping into .NET Core". WPF and Windows Forms will be components that layer on top of the .NET Core runtime. If you want to use them, you will get them. If you don't want to use them, you will not. We already have precedent for that with the Windows Compat Pack [1]. We also have significant platform-specific implementations already [2].
We think developers will like the idea that they can take advantage of OS-specific functionality. We will look for more opportunities to do that on macOS and Linux, too. If we were ever to support the macOS Cocoa API, it would layer on top of the .NET Core runtime, too.
> We think developers will like the idea that they can take advantage of OS-specific functionality
And what about actually reading and taking in account what people are writing in your blog post comments, here or User Voice, sometime for _years_? It's seems rather clear that there is demand for a cross platform UI API and that the lack of it is hindering .net core proposition value and adoption.
I understand that it is not a decision your team can made only, but please stop dropping the "we're hearing you" meme when some important demands like that are automatically dismissed.
A few related questions: what is the biggest difference between Core 3 and Framework 4.8 in terms of APIs?
Superficially the difference was desktop and a few other areas. Is there a reason to keep both branches of the ecosystem if the API surface grows ever more similar?
Second: is the goal of Core 3 to be “feature complete” for the desktop APIs in the sense that existing .NET 4.7 Windows Forms apps (for example) should work without change in .NET Core 3, or is it a less ambitious plan initially?
Some apps might run completely unmodified, but that's not really our plan. We intend for folks to update their apps to target .NET Core 3. We intend to support all the APIs that we find that client apps use. We're not including ASP.NET Web Forms, for example, but we'll definitely be supporting System.Drawing.
We've already shifted to putting more effort into the .NET Core project. The last few .NET Framework releases have been pretty targeted. That trend will continue. We'll continue adding existing .NET Framework APIs on Core to make it so that devs can move more and more apps to .NET Core. That's the basic plan.
From the post:
* Desktop applications will need to target .NET Core 3 and recompile.
* Project files will need to be updated to target .NET Core 3.
* Dependencies will not need to retarget and recompile. There will be additional benefits if you update dependencies.
I already ported a couple of .NET Framework desktop applications into Java instead of .NET Core, because customers wanted to go multi-platform, but were not happy with the lack of GUI support on .NET Core.
The main issue is that there is currently .NET Core (used mostly by web applications) and .NET Framework (used mostly by Windows applications), and many things that can be done in both have to be done in slightly different ways. Sometimes I'll look up how to do something in .NET, and find a reference that doesn't work in my app... because it's only there in Core, for example. .NET Standard was the first big step, I think, in starting to clean this up: Making a clear measure of what you could expect to be common to all flavors of .NET.
The goal here, I think, is to inevitably ensure regardless of platform you're targeting or format your application is used in, it can rely on the same .NET as every other.
Whereas .NET Framework was a Windows-based design where the OS was an assumption, .NET Core is moving to add Windows-specific capabilities as an add-on.
Yep, that is a side effect of rebuild the world with UWP and what ASP.NET team was doing (.NET Core 1.0) before acknowledging that it wasn't actually flying, now it is taking them a couple of years to steer the ship back on track, while trying to gain the confidence of developers with 15 years of development investment in .NET Framework.
This is really where I've been waiting for .NET to reach. There's been a huge amount of fragmentation in the .NET space, and until Core was able to handle existing Windows applications, it wasn't really done.
I'd still really like a desktop UI flavor of some sort to make it into cross-platform .NET, mind you. Let me run my desktop apps on a Linux machine.
I'll have to look into that. I have a WinForms app I'd love to run on a Linux machine. (Or more specifically, one of my Windows machines I run it on I'd rather be running Linux.)
I have to have a UI, but the UI is not sophisticated, and could likely be migrated to another UI framework without too much pain.
Regardless, I'm working on a way to build Qt/Qmp apps with .NET Core.
https://github.com/pauldotknopf/net-core-qml