At Microsoft Build Live today, we are sharing a first look at our plans for .NET Core 3. The highlight of .NET Core 3 is support for Windows desktop applications, specifically Windows Forms, Windows Presentation Framework (WPF), and UWP XAML. You will be able to run new and existing Windows desktop applications on .NET Core and enjoy all the benefits that .NET Core has to offer.
We are planning on releasing a first preview of .NET Core 3 later this year and the final version in 2019. We will be looking for developers to partner with us, to give us feedback, and to release versions of your applications in the same timeframe as our releases. We think that .NET Core 3.0 will be one of the most exciting .NET releases we’ve ever released.
ASP.NET Core will continue to move forward in parallel and will have a release with .NET Core 3.0. Our commitment to web and cloud applications remains unchanged. At the same time, it’s time to add Windows desktop applications as another supported workload for .NET Core. We have heard many requests for desktop applications with .NET Core and are now sharing our plan to deliver on that. Let’s take a look at that.
Benefits of .NET Core for Desktop
There are many benefits with .NET Core that are great for desktop apps. There are a few that are worth calling out explicitly:
- Performance improvements and other runtime updates that will delight your users
- Super easy to use or test a new version of .NET Core for just one app on a machine
- Enables both machine-global and application-local deployment
- Support for the .NET Core CLI tools and SDK-style projects in Visual Studio
We’re also announcing a set of improvements that we’ll be adding to both .NET Core 3.0 and .NET Framework 4.8:
- Access to the full Windows 10 (AKA “WinRT”) API.
- Ability to host UWP XAML controls in WPF and Windows Forms applications.
- Ability to host UWP browser and media controls, enabling modern browser and media content and standards.
.NET Framework 4.8
We’re also announcing our plans for .NET Framework 4.8. after shipping .NET Framework 4.7.2 only a week ago. We expect the next version to be 4.8 and for it to ship in about 12 months. Like the past few releases, the new release will include a set of targeted improvements, including the features you see listed above.
Visualizing .NET Core 3
Let’s take a look at .NET Core 3 in pictorial form.
Support for Windows desktop will be added as a set of “Windows Desktop Packs”, which will only work on Windows. .NET Core isn’t changing architecturally with this new version. We’ll continue to offer a great cross-platform product, focused on the cloud. We have lots of improvements planned for those scenarios that we’ll share later.
From a 1000-meter view, you can think of WPF as a rich layer over DirectX and Windows Forms as thinner layer over GDI Plus. WPF and Windows Forms do a great job of exposing and exercising much of the desktop application functionality in Windows. It’s the C# code in Windows Forms and WPF that we’ll include as a set of libraries with .NET Core 3. Windows functionality, like GDI Plus and DirectX, will remain in Windows.
We’ll also be releasing a new version of .NET Standard at the same time. Naturally, all new .NET Standard APIs will be part of .NET Core 3.0. We have not yet added Span<T>, for example, to the standard. We’ll be doing that in the next version.
C#, F# and VB already work with .NET Core 2.0. You will be able to build desktop applications with any of those three languages with .NET Core 3.
Side-by-side and App-local Deployment
The .NET Core deployment model is one the biggest benefits that Windows desktop developers will experience with .NET Core 3. In short, you can install .NET Core in pretty much any way you want. It comes with a lot of deployment flexibility.
The ability to globally install .NET Core provides much of the same central installation and servicing benefits of .NET Framework, while not requiring in-place updates.
When a new .NET Core version is released, you can update one app on a machine at a time without any concern for affecting other applications. New .NET Core versions are installed in new directories and are not used by existing applications.
For cases where the maximum isolation is required, you can deploy .NET Core with your application. We’re working on new build tools that will bundle your app and .NET Core together as in a single executable, as a new option.
We’ve had requests for deployment options like this for many years, but were never able to deliver those with the .NET Framework. The much more modular architecture used by .NET Core makes these flexible deployment options possible.
Using .NET Core 3 for an Existing Desktop Application
For new desktop applications, we’ll guide everyone to start with .NET Core 3. The more interesting question is what the experience will be like to move existing applications, particularly big ones, to .NET Core 3. We want the experience to be straightforward enough that moving to .NET Core 3 is an easy choice for you, for any application that is in active development. Applications that are not getting much investment and don’t require much change should stay on .NET Framework 4.8.
Quick explanation of our plan:
- 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.
We intend to provide compatible APIs for desktop applications. We plan to make WPF and Windows Forms side-by-side capable, but otherwise as-is, and make them work on .NET Core. In fact, we have already done this with a number of our own apps and others we have access to.
We have a version of Paint.NET running in our lab. In fact, we didn’t have access to Paint.NET source code. We got the existing Paint.NET binaries working on .NET Core. We didn’t have a special build of WPF available, so we just used the WPF binaries in the .NET Framework directory on our lab machine. As an aside, this exercise uncovered an otherwise unknown bug in threading in .NET Core, which was fixed for .NET Core 2.1. Nice work, Paint.NET!
We haven’t done any optimization yet, but we found that Paint.NET has faster startup on .NET Core. This was a nice surprise.
Similarly, EF6 will be updated to work on .NET Core 3.0, to provide a simple path forward for existing applications using EF6. But we don’t plan to add any major new features to EF6. EF Core will be extended with new features and will remain the recommended data stack for all types of new applications. We will advise that you port to EF Core if you want to take advantage of the new features and improved performance.
There are many design decisions ahead, but the early signs are very good. We know that compatibility will be very important to everyone moving existing desktop applications to .NET Core 3. We will continue to test applications and add more functionality to .NET Core to support them. We will post about any APIs that are hard to support, so that we can get your feedback.
Updating Project Files
With .NET Core projects, we adopted SDK-style projects. One of the key aspects of SDK-style projects is PackageReference, which is a newer way of referencing NuGet packages. PackageReference replaces packages.config. PackageReference also make it possible to reference a whole component area at once, not just a single assembly at a time.
The biggest experience improvements with SDK-style projects are:
- Much smaller and cleaner project files
- Much friendlier to source control (fewer changes and smaller diffs)
- Edit project files in Visual Studio without unloading
- NuGet is part of the build and responsive to changes like target framework update
- Supports multi-targeting
The first part of adopting .NET Core 3 for desktop projects will be migrating to SDK-style projects. There will be a migration experience in Visual Studio and available at the command line.
An example of an SDK-style project, for ASP.NET Core 2.1, follows. .NET Core 3 project files will look similar.
Controls, NuGet Packages, and Existing Assembly References
Desktop applications often have many dependencies, maybe from a control vendor, from NuGet or binaries that don’t have source any more. It’s not like all of that can be updated to .NET Core 3 quickly or maybe not even at all.
As stated above, we intend to support dependencies as-is. If you are at the Build conference, you will see Scott Hunter demo a .NET Core 3 desktop application that uses an existing 3rd-party control. We will continue testing scenarios like that to validate .NET Core 3 compatibility.
Next Steps
We will start doing the following, largely in parallel:
- Test .NET Framework desktop application on .NET Core to determine what prevents them from working easily. We will often do this without access to source code.
- Enable you to easily and anonymously share dependency data with us so that we can collect broad aggregate data about applications, basically “crowd voting” on the shape of what .NET Core 3 should be.
- Publish early designs so that we can get early feedback from you.
We hope that you will work with us along the way to help us make .NET Core 3 a great release.
Closing
We have been asking for feedback on surveys recently. Thanks so much for filling those out. The response has been incredible, resulting in thousands of responses within the first day. With this last survey, we asked a subset of respondents over Skype for feedback on our plans for .NET Core 3 with (unknown to them) our Build conference slides. The response has been very positive. Based on everything we have read and heard, we believe that the .NET Core 3 feature set its characteristics are on the right track.
Todays news demonstrates a large investment and commitment in Windows desktop applications. You can expect two releases from us in 2019, .NET Core 3 and .NET Framework 4.8. A number of the features are shared between the two releases and some others are only available in .NET Core 3. We think the commonality and the differences provide a great set of choices for moving forward and modernizing your desktop applications.
It is an exciting time to be a .NET developer.
Excellent, a missing piece falls into place.
Sorry for newbie question.
Dose this mean we are oona have wpf on linux?
We are making it possible to use .NET Core to run Windows desktop applications, on Windows. There is no support for Linux or macOS. This is covered in the post.
So platform specific items are being re introduced into core, whats the point in cross platform then.
From the post:
‘Support for Windows desktop will be added as a set of “Windows Desktop Packs”, which will only work on Windows. .NET Core isn’t changing architecturally with this new version. We’ll continue to offer a great cross-platform product, focused on the cloud.’
WPF, for example, isn’t being adding to the .NET Core runtime directly. It will be available as an add-on. That’s the “desktop pack” idea. The product is already layered and will remain layered.
We think this plan is the best of everything we offer:
– Small base runtime that is cross-platform.
– ASP.NET Core, for example, is a cross-platform component that layers on top of the .NET Core runtime.
– We also offer packages that are operating-specific, such as the Windows Compat Pack[1]. WPF will be like that. On Linux or macOS, we will also offer OS-specific APIs, like daemons or specific crypto.
[1] https://blogs.msdn.microsoft.com/dotnet/2017/11/16/announcing-the-windows-compatibility-pack-for-net-core/
If you are not changing .NET Core – why should it be new major version of .NET Core then?
Can it be released just as “Windows Desktop Packs” for .NET Core 2.1?
As I understand that WPF rely massively on DirectX and WinForms on GDI, maybe will be great to have all the logics and XAML parsers in .NET Core sources, then let partners in the .NET Foundation contribute to the proper renders. You clearly state in the post that the C# code will be included, but there’s no mention on how it will be included, or even if the packs will share source code with the developers. I hope so, as I think WPF is a great piece of tech, and allow WPF desktop application on Linux or Mac, using renderers based on Vulcan or Metal will be exciting and a good entry point for the .NET ecosystem on such OSes.
I’m sorry Rich but people have a point here. When you title your post “.NET Core 3 and Support for Windows Desktop Applications” that’s what the readers expect to get: Winforms in Linux. Heck that’s why I clicked on the link. And judging from the rest of the comments, I wasn’t the only one.
You might want next time to title the article as “.NET Core 3 and Support for Desktop Applications only for Windows”. That might save you some time and your readers some excitement-disapointment roller coaster.
Cheers
Stelios
We do understand that WinForm relies on GDI and WPF on DirectX so porting to other platforms costs too much. But why not porting UWP which is new?
No Paint.NET for Linux 🙁
Pinta is basically Paint.GTK
I feel like the Achilles heel of .NET is the subpar support for a cross-platform GUI. Microsoft really needs to provide a good cross-platform GUI API.
Cross-platform? Where is it? This roadmap is a joke. Put more people working on .NET Core and make a real cross-platform framework for God’s sake. At least provide a simple cross-platform UI based on tcl/tk. It can be implemented quite fast with good developers. Hire them and go for it. Move!
Yes, having a cross platform UI toolkit would make .NET Core a really good alternative to Java and others and would boost .NET usage tremendously.
But I’m not sure it should be WPF (and definitely not Winforms). Something simpler built on top of WPF (with fallback to XAML) would be perfect.
Wow… sounds exciting and interesting. However, why would anyone want to host a UWP control in a WPF application? WPF’s Xaml model is FAR superior to UWP’s. UWP’s team has been struggling with the most basic of Xaml concept for YEARS, the most obvious example being Markup Extensions:
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml
Seriously. Three years now. 😉
Not sure why anyone would want to take a major step back when there is way more functionality and power in WPF. You might as well provide the ability to host an Atari 2600 control. It would provide more value. 😛
Hosting WPF in UWP would be useful in the same ways as hosting WinForms in WPF and vice versa. It is essential for many large enterprise applications developer over a long period of time.
In agreement @John… THAT would provide value. If I understood, though, the “value” proposition here is hosting UWP into WPF, not WPF in UWP as you are suggesting.
I’m in a mixed environment, my users mostly use vendor UI applications, and my team “bridges” those vendor desktop apps with monitoring, basic ETL, and a few advanced features we don’t want “give” to the vendors. We have a mix of 3-4 specialized WinForms apps, but still have 50% of our users on Windows 7 (including 32-bit Excel), so UWP is out.
All new “UI spikes” are done as web apps. We’re watching React Native, considering using it to pull together the small web apps and rewrite couple of the WinForms apps.
But since this announcement we’ve started discussing using UWP (Win10 only) to write a “thin
composite shell”, which I expect to be much smaller than React Native. It should be able to host old WinForms controls. It should be abel to use the new Edge/Chakra UWP web view to reuse React/Vue assets in the “composite” app (we’ve been waiting for “evergreen” rendering engine, which is promised for this new UWP web view control).
The users who insist on staying on Win7 could keep using separate apps (a few web apps in Chrome, a few WinForms apps on 4.7).
This is how we are seeing it, too.
actually Mike seems to be joking about the value of that proposition – I guess at first steps of evolving a WPF app you’d place UWP in it, but eventually you might want to have a UWP app with some WPF stuff in it that you can’t (or it is too costly or black-box third-party stuff) port to UWP
When I started reading the article I got a bit excited because I started thinking you’re gonna port WPF to .NET Core. Realizing what you’re actually doing turned me back off again.
You should make UWP xplat. That would make me happy. Xamarin.Forms is so far behind in every possible aspect.
One example that comes to mind: a replacement for WinForms/WPF WebBrowser, which is stuck with the old IE engine (which is no longer maintained). Presumably, this lets you host Edge in WinForms/WPF.
Honestly, that’s exactly the same scenario I wanted. So why go all the way to embedding UWP instead of just enabling the WebBrowser?
Enterprise will definitely benefit though.
It enables transitional scenarios where you are transitioning to UWP syntax, or even to Xamarin Forms that is targeting UWP – though Xamarin 3 has a WPF target in a preview state.
Hosting edge instead of IE, will be nice. Otherwise, @Mike-EEE is right, why would you put UWP in WPF? Maybe it’s a concession to the people who actually built something in UWP and want to repent of that mistake.
There are a lot of UWP controls being developed.
This move could unify 3rd party controls: they produce UWP controls and you can use them in UWP and WPF apps.
XAML is not relevant to the question of using UWP controls in WPF.
UWP MediaElement is more powerfull. I want to use UWP MediaElement in WPF.
UWP beats WPF in many ways. UWP does things in a modern way. The ecosystem has shifted from what WPF satisfied.
I have noticed that people who hate UWP possibly hated WPF too when it came out after Windows Forms, and these people are people who value just business logic but have very much disregard for UI design, UX, responsive design and adaptive design. They only mostly care about the app working, whether it’s intuitive to the user or not. This is a bad mindset. So, basically, the hate shifted from WPF to UWP. It’s just a hate for actually having to prototype and code the UI, UX, etc., not even a problem with XAML. They just wanna drag and drop buttons and data grids and call it a day, instead of thinking of UX and intuitive UI.
UWP has solved the UI, UX, responsive and adaptive design expectations, that WPF tried to do in a old way, and also does all that WPF does that is needed today. Not everything WPF does is needed in today’s multi-device form factor world.
Btw, whether or not OEMs make phones to run Windows, UWP still covers responsive and adaptive design scenarios. UWP is the future.
All the hate for UWP is unnecessary. The world has evolved beyond WPF. It’s just hard to admit for some people. XAML Islands is a kind enough feature for UWP and Windows Forms.
Will WinForms and WPF be open sourced on GitHub and take community pull requests?
We are investigating that, but haven’t yet made a decision. We’ve been focused on the parts I’ve written about above. We see the value it would have, but don’t have anything to announce yet.
Came here to ask the same question. Please do your best to open source WPF, there’s loads of cool stuff we could do!
I agree. WinForms might not be worth the effort because it is so Win32 specific anyway. However, WPF, while still relying on Windows technologies for the graphics acceleration, is still on a much higher level of abstraction and thus more useful to the community. It might especially be a boon for guys on e.g the Avalonia project.
Cross-Platform WPF will beat Electron-based Apps
One more vote to have WPF open sourced. And may as well do it now rather than wait for pre-release Core 3.0
Wow, amazing work! Looking forward to .NET Core 3.0. I can’t wait to try to port my existing WPF apps to .NET Core 3.0.
Thanks also for sharing this long term planning till 2019. Highly appreciated.
And thanks for the survey. I also want to thank Dante Gagne from Microsoft for taking the time for a Skype call with me and many others!
Yes, it is definitely an exciting time to be a .NET developer.
It was my pleasure to get the chance to chat. The hardest part about the phone calls I was doing recently was knowing about the stuff we were planning to announce and not being able to chat more openly about it.
I’m glad you get to share my excitement on it too! 🙂
yeah, you didn’t overstate it on the call. I hadn’t expected something quite this big. Thanks for listening to devs and responding.
Shame we have to wait so long for the SDK project convertor, but at least there is a reasonable open source alternative: https://github.com/hvanbakel/CsprojToVs2017
Neat! But why 12 months for .NET 4.8? Was starting to like new releases coinciding with each Windows semi-annual release. So no new one coming this fall?
We want to apply all of our efforts to the project you see in this post. And we want to enable the shared features (like hosting XAML controls) for .NET Framework and .NET Core at around the same time. This is what is motivating the 12 month timeline.
Correct. We do not intend to ship another .NET Framework version between 4.7.2 and 4.8.
On 2019 all this effort only valuable for old applications to assimilate Net Core but nothing else… Electron and similar frameworks will win if this is not doing as expected: a real Microsoft proposal to cross platform UI based on XAML and very closed to WPF, that is the best UI platform ever done…
How about giving us something that works cross platform and uses HTML/CSS? Like support for Electron natively.
Have your vote counted and ignored towards this very ask here, @WT:
https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/10027638-create-a-ubiquitous-net-client-application-develo
Over two years and counting now as Under Review.
Guys, MS will NEVER create a desktop app building functionality that has non-Windows usage. Xamarin is as far as they would go and even that was self serving (to shamelessly promote UWP). Allowing .NET devs to write fast, efficient WPF like applications for Mac/Linux? 🙂 never gonna happen, regardless of the background tech, be it XAML or HTML.
Xamarin Forms 3.0: Supporting (some in preview) iOS, MacOS, Android, GTK, UWP, WPF, and Tizen.
It also now supports CSS for styling that then compiles to standard styles.
That’s why I switched to Progressive Web Apps – now I have one Web&Desktop app working on all platforms with ease 🙂
They should just make Microsoft Linux Desktop OS. I’m totally serious.
Ugh … HTML / CSS … no, just no. It’s bad enough having to endure those twin train-wrecks writing browser-based apps. Don’t let the cancer spread.
Couldn’t agree more. HTML/CSS/JS wasn’t designed to go that far. Those are 80’s and 90’s things extended to the limit. The web world is a pain because the bare bases are inadequate.
Exactly. XAML in the browser is what I’d like to see. Never going to happen though.
Here’s your XAML in the browser https://github.com/praeclarum/Ooui
XAML in the browser was WPF/E aka Silverlight. Worked like a charm, then browser plugins died and everything switched to HTML5. Without a plugin, allow WPF content only in Edge, that’s also a UWP app, it’s simply useless. Better if Microsoft releases partial sources on GitHub and allow the implementation of native renderer for WPF based on techs available to the targeting OS, like Metal or Vulcan.
No excuses in regards to plugins, @Alessandro. MSFT could have easily taken the JSIL route:
http://jsil.org/
But that would have required a little bit of innovation… something it would seem was lacking in 2011, for some reason. 😉
You can with Web Assembly. Perhaps it’s not “official” MS but it’s outstanding
https://github.com/praeclarum/Ooui
So .net core based winform app will be run on Windows only or on other platform too (linux,mac) ?
Windows-only. WPF and Windows Forms have deep dependencies on Windows as covered in the post. See:
“From a 1000-meter view, you can think of WPF as a rich layer over DirectX and Windows Forms as thinner layer over GDI Plus. WPF and Windows Forms do a great job of exposing and exercising much of the desktop application functionality in Windows. It’s the C# code in Windows Forms and WPF that we’ll include as a set of libraries with .NET Core 3. Windows functionality, like GDI Plus and DirectX, will remain in Windows.”
But… it’s an abstraction!!! What’s preventing you to come up with implementations for other platforms? Doesn’t make any sense.
Windows Forms is a very leaky abstraction that exposes a lot of the underlying Win32 platform to applications; and given that their goal is to ensure existing applications can be ported over without changes, it has to *remain* a leaky abstraction.
The leakiness of the abstraction means it’s basically impossible to make it compatible with other platforms, because it would mean having to reimplement a large share of the Win32 API underneath so that all the applications that went around WinForms’ abstractions will still work (and make no mistake, *every* non-trivial WinForms application does it).
The Mono project tried making a cross-platform WinForms that handles all that headache, and it was never ‘great’ and never got to the point of being a drop-in, no-code-changes-necessary replacement for WinForms on Windows.
Well, if the wine team can do it, Microsoft can definitely do it. If Sun could do it, Microsoft can do it. The limitations are not technical, purely business. And out of the two Winforms and WPF, WPF can definitely be ported, most of the work is building a rendering engine for each operating system.
.Net Core contains enough breaking API changes vs. .Net Framework that the same could have carried over to a new UI API. .Net Core also has a history of reimplementation. I clicked on the link to this article, hoping to read about a new Forms API that was similar to the old, but disentangled from GDI/Win32, or even a new (likely UWP like), cross platform UI API entirely.
I don’t want to complain, Microsoft make amazing tools for developers, this is just way short of what I, and obviously others has briefly hoped for. It’s also far from “one of the most exciting releases ever”, and really just feels like a step in phasing out the .Net Framework for .Net Core, no bad thing for me but not much of a revelation either.
Timothy, your wrong.
Mono supports >Dot Net 4.5
a. Mono is cross-platform
b. handles WinForms
c. is a drop-in, no-code-changes-necessary WinForms
try it, copy winform exe across to Linux/Mac
Open Terminal
> mono helloworld.exe
It works, Full Winform GUI!
So it means more code will get ported to Java, Qt or Electron.
The longer Microsoft ignores GUI support on .NET Core outside Windows, the less relevant it becomes for portable native applications.
Even the VSCode team has been forced to use Electron, when it could have been such a good use case of portable .NET code.
I agree. Not so long ago there has been some discussions about this and the vast majority was agreeing that having a unique platform independent approach in the back-end (.NET core) and a polatform indepdent GUI (XML Standard) is necessary. What Timothy Fries tells us that of course WinForms has historic reasons why it does not work to make it platform independent, but XAML/WPF almost has.
So when thinking about something new it doesn’t make sense to think about the old things. I understand that a lot of developers are still working with WinForms, but if the argument is to still support all the WinForms users/developers then UWP should have never been introduced, because it means that MS fears to make the WinForms guys angry.
I did WinForms a lot, and I understand that large enterprise applications still have to works with WinForms, but in the last few years there were only a few updates on WinForms (e.g. HighDPI, etc). Doesn’t it make sense to leave WinForms as it is, only release bugfixes and updates to comply with the current Windows platform updates?
On some day you really need to cut of the old things as you did with MFC? Or are there still developers that want high DPI support for MFC?
GUI development is kinda mess, Electron bases on V8, Java has Swing/JavaFX, but they’re not really pleasant to use, Qt has problematic licenses, there’s also GTK, but it’s API isn’t nice as well.
Microsoft could probably create alternative for Electron/V8 using their Edge browser engine and C#, but Edge is tightly integrated with Windows as well.
It seems like only sensible alternative is to create cross-compatible GUI framework from scratch and that probably would take few years.
AvaloniaUI is a GUI framework that has been in development for a few years. It looks promising.
Yes, Electron, Swing/JavaFX and Qt do have their own set of issues and not everything is perfect, but they exist and are an industrial option, used by millions of companies to deploy their desktop applications.
Currently there isn’t any such option for .NET Core and this announcement just kind of waves it away.
Xamarin.Forms is not an option as it lacks the same maturity level that those tools, although not perfect, already offer across OS X, UNIX variants (not only Linux), and Windows.
I have already ported a few applications from .NET to Java, as customers are not confident on .NET Core’s roadmap for portable desktop applications.
Qt does not have problematic licenses
Currently, they are enhancing Xamarin Forms that direction, though it compiles natively for the target platforms. Including preview, with Xamarin Forms 3.0 released today you can now compile for iOS, Android, UWP, WPF, MacOS, GTK, and Tizen.
I agree “The longer Microsoft ignores GUI support on .NET Core outside Windows, the less relevant it becomes for portable native applications.”
Avalonia https://github.com/AvaloniaUI/Avalonia
They had a solution with Silverlight. Cross-platform XAML based GUI that was like coding in WPF. But they have chosen to throw it out. The earlier comment about it being too hard is rubbish.
The browser plugin is dead. Silverlight was great but it doesn’t mesh with the times.
Web Assembly + Xamarin Forms from
https://github.com/praeclarum/Ooui
is promising.
Windows Forms .exe apps have been working under Linux without any changes for more than a decade. (Using Mono – a third-party lib)
Now you’re telling us that’s impossible for Microsoft which created that.
P.S. Not that I care much about WinForms….
Yes Ark, Winform dotNet 4.5 apps just work on Linux and Apple desktops.
Open Terminal
>mono helloworld.exe
Winform UI apps work cross platform, just put mono in front…
To install full Dot Net framework on Linux/Mac
>sudo apt-get install mono-develop
Is there possibility of a multi-platform desktop application platform for .net core in distant future?
Vote for that exact idea here @Jinseoung:
https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/10027638-create-a-ubiquitous-net-client-application-develo
Left my 3 voices as well. Thanks Mike-EE, I am thinking same way as you!
Is Blazor what you are looking for?
https://blogs.msdn.microsoft.com/webdev/2018/02/06/blazor-experimental-project/
It’s close, @Sukesh. I for one am VERY appreciative of MSFT stepping out and seeing what WASM is and how it can be used. However, it’s WASM-only and it’s not meant for the other 3 platforms: iOS, Droid, and Windows. Plus at the end of the day it is HTML/CSS and as developers have shown here, that is not a preferred technology. It’s all about the Xaml as I discuss here:
http://blog.developers.win/2015/10/ubiquitous-qualities/#xaml-powered
Nearly 3 years ago… and counting. 😉
We don’t have any plans for that now. We’re focused on enabling Windows desktop applications with this project.
what they are doing is not what the community wants, the community wants multiplatform GUI
(WPF for Mac/Linux)
The “community” does not express support for Linux desktop UI when they vote with their wallet. It is a tiny and vocal minority representing 1% of desktop market share (ok, maybe 2%). There is practically zero business sense to develop client applications for Linux. For Mac, you are forced to use Apple build tools. Nothing Microsoft can do about that. So Kudos to Microsoft for not giving in to this type of irrational economic theory and for showing exceptional restraint and professionalism in response to criticism.
25 years programming on Windows platform and in all those years I saw one amazing technology which we all know wasn’t sustainable due to the plugin side of the equation for all major browser this wasn’t acceptable.
Now with all my experience and knowledge, I see what enterprises need. It’s called WEB APP and those like me that needs to do these WEB APPS have to endure a very poor foundation, a multitude of syntax and libraries and I see what Visual Studio is becoming because of that : A MESS
Let me explain a bright future we all want : Remember Silverlight development ? Well that’s the need, XAML for UI and C# everywhere not counting the simplicity of development CLIENT-SIDE APP
Why this was so difficult to do with Razor at that time when it was created ? Don’t tell me it’s impossible to have GUI to place elements on the screen which we can bind to EF entities in some way ?
Don’t get me wrong, I don’t see anything innovative with Blazor. I’m actually in a time where I have to write code for a long time just for so little compared to WPF or Silverlight which coding very little was giving so much. We need either WPF or SILVERLIGHT for the web. There’s nothing else to add.
Totally agree! Xaml for UI and C# everywhere.
Xamarin.Forms has a pre-release of WPF now, meaning that it covers Windows, Mac and Linux desktop. It is mono but that will become more and more like .Net Core and hopefully will merge with it in future. I hope Xamarin.Forms expands its desktop controls for devs that care more about desktop than mobile.
If Win Forms, WPF, and UWP will land in (new) NET standard (as image shown), then who will write implementation of it on non-windows platforms ?
We don’t see WPF, Windows Forms, and UWP as being cross-platform desktop solutions. So, we don’t expect anyone to implement them on other operating systems.
That’s a sad and bad decision. Silverlight was great because it as also targeting Mac OS. On the other side UWP is very uninteresting as I didn’t even allow to build software for most Windows 7 which still accounts for half of the Windows machines out there.
Porting technologies such as WPF to .NET Core sounds great, but Microsoft should invest more energy to build a cross platform GUI and blow Java away.
@David : Thumbs up man
The ported MS-Office to mac and mobile devices and they haven’t thought about cross Plattform gui?
I can’t believe this.
now, your question is answered by Microsoft, they are using React native to rewrite office 365’s cross-platform UI. Microsoft is now more open and more willing to adopt open-source technologies.
We have replicated most of the winforms class library plus a large number of enhancements and new controls in wisej. The controls generate json packages that are rendered in any browser by a javascript library using websocket for push updates. It runs also on Linux using mono. It can be self hosted with owin/katana, and it can be packed in a desktop app like electron, but much better since we generate a single exe either embedding IE, or Chromium or FireFox or Edge. There is a nice review on codeproject https://www.codeproject.com/Articles/1208339/Wisej-The-Easy-Button-for-Enterprise-Software.
It’s currently being used in large LOB apps that are otherwise close to impossible to build using html based frameworks. These apps need a control winforms/wpf-like development model.
Can you please consider WCF for asp.net core pipeline?
We are considering it. We would like to hear more feedback from folks who need to expose WCF services, either on the client or server.
I’m curious why would someone need WCF while there WebAPI or SignalR on the .NET Core.
Large base of already existing enterprise grade software using WS-* standards. No one will rewrite this to web api, that would be insane and mostly provide no real benefit. Web API is very low level when comparing to WCF which logically operates on a contract level. Moreover in many use cases it is still faster than web api in .net core even with all abstractions it provides, see https://www.erikheemskerk.nl/benchmark-wcf-webapi-aspnetcore-mvc/ (what an irony!)
long discussion on this subject
https://github.com/dotnet/wcf/issues/1200
Oh, thank you for saying this. I feel so hopeless surrounded with all this kool aid drinking. .NET has been drowned by dotCOM collapse leftovers and people who have difficulties understanding XML are now driving our future on desktop. They are literally rewriting .NET Framework in a dumbed down way, I don’t think they even remotely understand how things work in enterprise, which is totally bizarre because they knew that when they were building .NET Framework. I do not know what their end goal is here, kill WPF/WCF like they did Silverlight?
WCF guys can just stay with the legacy .net framework with their legacy enterprise apps. You don’t need the new .netcore, the old can satisfy your needs
There is HTTP/2, GRpc, Protobuf, with cloud native times (think about kubernetes, service meshes, that already have support for these protocols), it would be better to integrate them into C#/.NET Core ecosystem instead wasting resources on WCF. For messaging there’s NATS.
Microsoft is always trying to discover the wheel, but it would be better to just accept modern standards and base new frameworks on them or just simply focus on integrating them.
Just leave WCF like we left Win/WebForms, in the past.
will you give me 3 mln usd to rewrite software? thanks. With tons of web services and integrations. real money is here, in banking and enterprise systems. That products drive my clients’ every business day by day, month by month, year by year. And you are telling to rewrite them to web api, for what’s sake 😉 there is no business benefit behind it. Especially when WCF provides same or better performance. There is no business case that would validate funding.
so there is massive amount of existing code base used by banks, financial institutions, large enterprises, etc. If Microsoft is still going to be typical Microsoft it used to be for years (ie forget their own toolkits and libraries and loyal customers) that money will be finally put elsewhere.
Making decent soap stack available on .net core would give a real boost in .net core adoption. that’s my opinion. in other words – that’s a blocker for .net core adoption.
Of course all of this buzzwords you mentioned are part of my stack for new ventures.
I’m just saying, it should not be priority.
.NET Core was move in right direction, but Microsoft always tries to develop everything from scratch, WCF is barely developed anymore. I like C#/.NET Core, but WCF is part of legacy, it was always overcomplicated, underdocumented mess, tightly integrated with Windows.
Microsoft should focus on integrating quality and accepted, modern standards instead creating and maintaining inferior products.
For god sake, we are in 2018 and even with .net core, we can’t generate code coverage from command line without VS! https://github.com/Microsoft/vstest/issues/981
Why would I want support for legacy, when even .NET Core ecosystem is not fully mature and so basic features are still missing?
I understand that rewriting huge systems just for sake of rewriting doesn’t offer business value, but either switching from .NET to .NET Core doesn’t give you any business value. Even if you have WCF on .NET Core, you would still need to rewrite these huge systems to take advantages of .NET Core (linux, kubernetes) and you would still have a lot of dependencies that might not be easily portable to .NET Core.
Upgrading is always costly and I’m not convinced that sticking to WCF in modern software, would cut the costs significantly.
While I see some reasoning in your answer I can’t agree. I am developing software for ~20 years, mostly on MS platform and more importantly on .NET from its very beginning, now .net core for new projects. Microsoft is known for leaving its loyal customers behind with libraries, frameworks and server products. What enterprises want is stability, predictability and a clear vision. That’s why Java rocked in enterprises 15 years ago, 10 years ago and rocks now in Fortune 500 companies in mission critical software (well, Netflix is also Java house). So dear MS, do not complain about slow adoption in enterprises, do something.
I remember all that fuss with .net standard, all that going forward and then backpedaling on asp.net core compatibility. Sometimes I have a notion that all .net core stuff is developed by bunch of hipsters doing it just for the sake of doing it (famous quote from the Madagascar movie: Hurry up, before we all come to our senses). Now things start looking better, since .net standard 2.0 announcement I see more careful planning.
I am not saying that we need to bring full WCF server stack to .net core. We should take an opportunity to modularise it, provide key functionalities first and perhaps leave less used ones behind in the dust. Not having WS-* standards in .net core is simply pathetic.
Or if MS does not want to cope with that open source WCF code, ppl will do the stuff. Now it is under closed source license.
Yes please, binary format WCF services exposed on the server.
Yes please. WCF with application/msbin1 for efficient large array transfers. (And DateTimes with proper timezone support)
Thanks 🙂
Long discussion thread which has all arguments I can think of is recorded on github, please look here : https://github.com/dotnet/wcf/issues/1200
In the enterprise side of things, nobody wants to get stuck on the old version of the framework their using, but there are many enterprise users of WCF especially for internal APIs (where each business domain is covered by one or more API). Providing a ‘WCF’ pack (basically WCF, for windows, as a NuGet etc) would provide a migration path. It may be that WCF itself needs to be open sourced in order to get people to keep maintaining it, as I’m sure there are not many volunteers at Microsoft.
I’m so excited! 🎉
Here’s my burning question: will Windows Forms and WPF libraries be open-sourced, maintained in corefx or some other repo? Will discussions and contributions be welcome just like the existing libraries in corefx?
Great question. The answer is TBD.
We love open source. We haven’t done any due diligence yet with Windows Forms and WPF to validate that we can deliver the same open source experience as we have with corefx, for example. I hope that we’ll have an answer for this when we talk about .NET Core 3 next time.
Thank you. I appreciate your thought. You folks are incredible! My year is already so much better!
Indeed… THIS would be a massively valuable announcement. Hoping for the best here. 🙂
How does this tie in with the Xamarin roadmap for cross platform desktop/mobile app development? Would Xamarin.Forms continue to be supported / developed or will it eventually merge into .Net Core?
Apologies if this isn’t the right forum.
Xamarin.Forms supports UWP XAML as a back-end, so you will be able to host Xamarin.Forms applications with .NET Core 3.
At Xamarin they seem to be recently talking about ditching XAML (silly choice in my opinion) for Xamarin.Forms
Xamarin.Forms is XAML – it just isn’t the same exact XAML as WPF (I’m assuming that’s what you meant).
But that’s why they’ve also created the XAML Standard.
Will .NET Core 3 and the desktop pack with WPF support run on Windows 7?
Windows 7 is supported with .NET Core 2. We haven’t locked the OS matrix for .NET Core 3, but we don’t have any specific plans on changing it.
Great question. Will this bring UWP to windows 7?
No. Nor would it come to windows 8.
They’re just exposing a nice way to share airspace between UWP components and WPF or WinForms.
I’d like to see both full framework 4.8, and core 3, still support Windows 7 if only because it means I can still deploy tools and utilities to the many win 7 clients out there, but also because without that support, the new framework and core won’t yet be adopted by enterprise and we’ll see a bit of a schism in the community. When win 7 goes totally end of life, and it’s indefensible to still have systems running it (no patches!) then we’ll see movement.
Windows 8 didn’t get the dame traction, but windows server 2012 (especially r2) got a LOT of traction. We have many deployments running on that, and many customers using it as remote desktop servers. I’d really like to see it properly supported with core and framework for several years. I don’t need UWP compat at all, but do want to target newer framework, and then eventually switch to core, for our ASP.NET medical records system. SignalR has been the thing making it unviable to switch, but with it coming online the main issue for me will be inertia and a massive testing project. Will be worth it, but I’d like to buy some time through to end of 2018 and then know I can still run on win 2008r2 for a bit longer… (I haven’t looked in to long polling in the new SignalR but my gut feel is that it won’t be there, which will mean all IE11 clients on Win 7 lose support for us regardless of server)
So we can run Win2D inside WPF by hosting UWP?
Yes. You will be able to use Win2D in WPF with .NET Core 3.0.
> Support for Windows desktop will be added as a set of “Windows Desktop Packs”, which will only work on Windows.
Does this include Windows 7? Specifically, I have a mixed WinForms/WPF desktop app and still plenty of Windows 7 users.
(Obviously, I wouldn’t be able to host UWP controls. But I’m still hoping for some limited WinForms/WPF on Core support.)
Windows 7 is supported with .NET Core 2. We haven’t locked the OS matrix for .NET Core 3, but we don’t have any specific plans on changing it.
Does that mean you don’t have any specific plans not to support win7 with .dotnet core 3?
A year plus from now? Really? More vaporware…
It is hard to make everyone happy.
One person’s “vaporware” is another person’s “Thanks also for sharing this long term planning till 2019. Highly appreciated.”.
Yes, it is highly appreciated, it’s important to the company I work with, and I believe there’s a lot of weight behind this.
Actually its not that hard. Just stick for once with your plans. Last year’s big thing XAML standard is … oh never mind.
Speaking of which, we’ve got a nice discussion around this and //build 2018 going on here:
https://github.com/Microsoft/xaml-standard/issues/230#issuecomment-387292869
I read the announcement and it is great!! Why is it vaporware? I think this is the right information politic. I don’t need Microsoft to “surprise” me with such a product. I would like to know it upfront. Why it this different than some other big companies with products that are more than 1 year in beta?
> Why it this different than some other big companies with products that are more than 1 year in beta?
The difference is MSFT has earned a notorious record of changing plans at least twice before this 1+ year period is over.
Thank you so much for your hard work on .net core! It’s an amazing product and it just works. Zero issues with anything so far.
Very interesting news. Looking at the calendar, 12 months is slightly past the 1903 semi-annual channel for Windows. Will .net 4.8 be a standalone drop or coincide with windows 1903. There’s also the windows server 2019 ltsc next year and I’m wildly guessing, a VS 2019?
Do you have any roadmap crossovers you might be able to share?
Best regards, Michael
Great questions, but we’re not there yet on those specific alignments. I suspect we’ll decide on those alignments in four-six months once .NET Framework 4.8 and .NET Core 3 projects are much further along.
Thanks!
Please, please consider fully open sourcing the xaml stack it self, i’m not talking about all the uwp and wpf controls or frameworks, just the xaml parsers. That way the community can add all the missing features in the different xaml flavors that then each framework uses.
You know it makes sense, and the xaml stack itself is not a massive code base, compared to the actual ui frameworks, I know you can make this happen 🙂
Maybe not very relevant, but is there any news for new Visual Studio Version?
Also please do not separate VS versions anymore. Give everyone VS Enterprise, free. We will pay for Azure, promise!
Is Microsoft currently planning on dropping support for any of the existing full .NET Framework versions or will 4.5.2, 4.6.0, 4.6.1, 4.6.2, 4.7, 4.7.1, 4.7.2, and 4.8 all be supported and getting security updates in 2019? That seems like a lot of supported configurations to develop patches for. If Microsoft is planning on end of life for some versions like what happened with .NET 4.0, 4.5, and 4.5.1 it would be nice to know the roadmap so we can start making plans.
I think thats one of the main goals. It will leave you, I think, with security issues that you have to patch your self.
Looking forward to try this on your Business Canvas WPF application!
I want to build apps in XAML which is the best markup on the planet while html/css after so many years seems to not allow many scenarios that XAML is capable of since it was born.
So PLEASE, make sure I can build XAML apps and be able to target web via WebAssembly – this will be HUGE!
I spent 20 years on Microsoft platform and this is my dream:
https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/10027638-create-a-ubiquitous-net-client-application-develo
Now I’m stuck at this crazy/retarded JavaScript world with hundreds of frameworks everyday and new Angular/Vue/React version every 2 months because… why not!!!!
MSFT – please fix it!
lol
LOL you read my mind…
Truer words haven’t been spoken. I love C# but the last year learning Angular and the like has been hugely annoying. Something like blazor or a single UI framework to rule them all would be incredible.
Currently I do this with Delphi/Firemonkey.
It’s amazing, .Net Core is a fast language for application development with a very fast learning
Oh yeah ? Is it as fast to develop a UI ?
LOL
Sorry if I missed the point, but what I can do today is build the non-UI against .Net Standard and run it in “classical” .Net 4.6+ underneath WPF/Forms. With the new approach I, can run WPF/Forms UI still on Windows only, but on top of .Net core.
What would we gain? Here is what I got so far:
– Include .Net Core with our Application, so I don’t have to wait for features on “classic” .Net
– Slightly better Startup time
– Host UWP controls in WPF/Forms
– Edge based WebView control
– I assume, hosting UWP controls still needs Windows 10. How to handle the 50% of our customers running Windows 7? Can I use at least the same binary/build? Do we have to clutter our source with #ifdefs?
Its for sure a step in the right direction, but to sell this to management, I need more. Especially after last years XAML standard is already old news…
Very good points, Joerg. I’m waiting for the answers…
Well, a .Net Standard library doesn’t mean it would run on .Net Core. According to my knowledge, you actually run .Net Standard class library on the top of .Net 4.6+ because of the type forwarding. So I don’t get where the “Slightly better Startup time” came from, did you use some other techs to do that and how you manage to include .Net Core with your WPF/Winform apps?
“We are planning on releasing a first preview of .NET Core 3 later this year and the final version in 2019. We will be looking for developers to partner with us, to give us feedback, and to release versions of your applications in the same timeframe as our releases. We think that .NET Core 3.0 will be one of the most exciting .NET releases we’ve ever released.”
How do we get on the list for partnering?
I’m really curious how the XAML Islands functionality is going to work. It’s been hammered into devs’ heads that the UWP ecosystem and the Win32 ecosystems are entirely different worlds and never the twain shall meet; and this is the first real deviation from that. Will XAML Islands require Project Centennial packaging? Is it out-of-process? Will the interface be documented and open to the point I can pull UWP controls into my legacy C++ application? So many questions, and there’s not even a block for it on the Build Live schedule!
>this is the first real deviation from that
File Open/Save Picker integration is an example of how UWP/WinRT XAML page can be hosted inside Win32 file open/save dialogs on the desktop.
hi .. great announcements … Im excited about your “self contained exes” …
Is this an evolution of the current “SCD (self contained deployment)” that you can already do with .NETCore? [documentation on SCD – https://docs.microsoft.com/en-us/dotnet/core/deploying/ ]
Or is this related to .NET CoreRT and .NETNative compiling down to exe using this toolchain ?
Would love to know your thinking around “self contained exes”
Thank you for having the wisdom to do this.
I was sad to see the side-by-side WPF effort disappear, but this is better. .NET Core enabling a fully bundled, possibly natively compiled and tree-shaken set of dependencies is worthy of applause on its own, as is porting EF 6 and supporting dependencies as-is. .NET Core still won’t have AppDomains, but being able to run additional processes in .NET Core should at least be less resource intensive than running them in .NET Framework.
Overall, this seems well thought-out, and many cheers to everyone involved for making a pragmatic decision that will really help those of us who develop and maintain WPF apps.
(I also encourage further investment in WPF once this comes to fruition – you will be on a much better foundation to do that.)
THIS
Regarding “EF6 will be updated to work on .NET Core 3.0, to provide a simple path forward for existing applications using EF6”, what does this mean exactly? Will EF6 migrations work again, since there is currently no way to run them from the .NET Core tools anymore?
As for “We will advise that you port to EF Core”, what does that mean for EF6 migrations? How will existing EF6 migrations be portable to EF Core? Is there a planned migration story for DB migrations? This is a P1 MUST if we’re EVER going to be able to move away from EF6.
Hello Marcel,
Good question. We plan to have the whole EF6 runtime running on .NET Core, but we haven’t decided yet completely on the tooling story.
We currently don’t have any plans to support EF6 migrations working on EF Core (I would really like to understand why you consider this a P1, so it would be great if you could create an issue on GitHub for this), but there are different options for making EF6 migrations work with EF6 on .NET Core.
For example, enabling the current PowerShell-based PMC migrations commands to actually run user code at design-time on .NET Core will require rearchitecting how the migrations tools work. Currently these commands execute user code in a separate AppDomain inside the Visual Studio process and take advantage of .NET Remoting to exchange information. Instead, we would likely have to adopt a an architecture to the EF Core commands, which run out-of-process.
Another alternative that would have constraints and result in a more convoluted user experience (but which would let us focus our efforts on other improvements) would be to require that the project be refactored to place the EF6 model and migrations into a separate library that can be invoked from either .NET Framework or .NET Core. This is similar to what you have to do today to work with EF Core migrations if your application runtime is UWP or Xamarin.
If you are interested in providing detailed feedback, the work to make EF6 work on .NET Core is currently tracked on the following GitHub issues:
– https://github.com/aspnet/EntityFramework6/issues/189 – Support PackageReference
– https://github.com/aspnet/EntityFramework6/issues/231 – Support for new csproj format
– https://github.com/aspnet/EntityFramework6/issues/271 – Support for .NET Core
Diego, Mohammed from Migrator.EF6 has saved the whole community with his CLI tool: https://github.com/mrahhal/Migrator.EF6
It runs side-by-side with the EF Core tooling with a simple ‘dotnet ef6 migrations…’ command and invokes the prior toolchain.
Any reason not to make this official and allow EF6 projects to officially run on .NET Core? (albeit Windows only)
Since the theme of .NET Core 3.0 seems to be focus-on-Windows anyways, it’s still a giant step forward until the full, cross-platform .NET Core support you mention above can be ready.
Is EF6 going to be available for Linux and Mac? If not, what does “EF6 (cross-plat)” in the diagram mean?
Svick,
Sorry, but we struggled to come up with simple diagram that could represent accurately the role of EF6 in the plan. Unlike the “desktop packs”, EF6 on .NET Core will not be Windows-Only and will not target *only* desktop apps. You can think about it as its own “data pack” that is cross-platform and can be used on either desktop or ASP.NET Core applications.
That said, there might be limitations depending on the availability of a cross-platform ADO.NET provider that you can use with EF6 on .NET Core.
Why would I want to use Desktop Pack + .Net Core instead of .Net Framework if both are Windows specific and .Net Framework is omnipresent on Windows?
Hoping for an answer to this question. Yes, I’m disappointed that WinForms/WPF won’t run on Mac/Linux, but I guess we have Xamarin for that, so no point in complaining about it. That said, I’m still not clear on the VALUE proposition of running desktop apps on “dotnet core”. I guess there’s some theoretical “isolation” benefits since dotnet core’s deployment model is more flexible than full dotnet. My guess is that there’s little “immediate” benefit to dotnet devleopers, but this is simply a stepping stone to the long-term direction of dotnet (which is still a little unclear at this point). This does also add significant confusion around the dotnet core story (which most people still equate to being “cross-platform-dotnet”).
Hi Tomasz, one advantage of .NET Core over .NET Framework is that we can innovate faster there. So you can take advantage of performance improvements, new API’s etc. Eg., Span.
One of the benefits would be that you can use the same versions of libraries on both your .Net Core based servers as well as your client applications. Otherwise, even if you use .Net Standard libraries in your app, they are actually executing in different versions of the framework.
Just curious, will it be possible to have both a UWP Window and WinForms Form in the same application project? Would it be possible to create a console app that occasionally shows UWP Windows (without the Store installer, sandboxing, etc.)?
If all desktop applications will share the same API it would be great. But I’m afraid it requires more sophisticated and modular app model. It seems to me that GDI+ (WinForms), DirectX 9 (WPF), and DirectX 11 (UWP) technologies don’t work well with each other.
You are killing .NET Framework so you can cram unwanted UWP and .NET Core down desktop developers’ throats because they wouldn’t adopt it on their own. Its uncanny. Who exactly made “many requests to move desktop dev to core”? We don’t need your core and you rewriting BCL, we need you to work on .NET Framework and expanding WPF, because that’s what you were all doing before you decided to become a service delivery company. And no, hosting UWP in WPF is NOT improvement, regardless of what web develoeprs tell you in the surveys. And it most certainly does not warrant 12 months release date.
You are terrible custodians of .NET Framework, you should open source it in its entirety (since you profess so much love for it). But you are not going to do that, are you? It would threaten your and Windows’ team continual attempts to resurrect the zombie corpse of UWP and would allow desktop developer community to migrate themselves and their clients to Linux. Prove me wrong, I dare you.
It most certainly is NOT an exciting time to be a .NET developer.
1. There is a new version of .Net Framework coming. Still Windows Only
2. This is an expansion of .Net Core. .Net Core is benefiting from a lot of speed and other improvements contributed by the community. Adding compatibility for Windows Forms and UWP will allow you to upgrade and take advantage of the newer tools and speed in the future while also being able to leverage cross-platform libraries easier. For example, if your server-side is running .Net Core, your client can be as well giving greater compatibility.
3. .Net Core is available for Linux and MacOS, so I don’t for sure understand your point, exactly.
4. Nothing is changing for the existing platforms right now. This is for the open future. Personally, though, if I was writing something new I would seriously look at Xamarin Forms.
If I understand it correctly, they are tired of all those desktop stuff. The main trends now are PWA, Xamarin, Clouds, AI, etc. Re-packing the old GUI platforms is just optimization for some internal processes. So they don’t need to update .NET Framework each time when they add new features to .NET Core (.NET Core is very important for clouds and will be further developed).
Sorry, but no. If you had 100+ million users to deploy to, you wouldn’t speak like that. Open sourcing internal code has legal implications, it is not just about what you “love” to work with when it comes to legal and compliance in a big multinational firm.
As anyone with experience of large scale deployment understands, improving WPF will likely require breaking changes and introduce regression bugs when moving quickly. This is practically impossible when you do not have side by side deployment because the bar for compatibility is set too high. When thousands of people have taken dependencies on bugs and quirks, you’re practically blocked from even fixing certain bugs. By moving to side by side deployment, it will allow the pace of development of WPF to increase dramatically without breaking existing applications. It is critical for the WPF/WinForms stack to move to SxS as a first step.
“improving WPF will likely require breaking changes and introduce regression bugs when moving quickly”
Gee, I wonder how any existing widely-used library or framework ever gets fixed or improved.
Will Windows services be supported with .net core 3.0?
While I appreciate the goal/objective this work could bring. The use of the .Net Core naming is a bad idea. IMHO the defacto meaning that comes to mind when you say .Net Core is cross platform. That is not what this is. Yes, you use the word Windows in the name but it is confusing.
There are already Windows-specific libraries that run on .NET Core, such as the existing Windows Compatibility Pack. You could also write Mac- or Linux-specific .NET Core libraries. I thought the image explained it very clearly: https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for-windows-desktop-applications/#user-content-visualizing-net-core-3
This is awesome news! Really looking forward to this release.
Heres’s another vote for open-sourcing the GUI libraries (yay winforms!), I think that would enable much innovation in this space.
Cool stuff!But the way you are naming Windows 10 is terrible.Go back to old way of naming Windows: Windows 7 sp1,sp2 etc.
You can give these names to Windows 10 .Like Windows 10 SP1,Windows 10 SP2 or Windows 10 Update 1,Windows 10 Update 2 or Windows 10 R1,Windows 10 R2.Now compare the sample names i provided to Window 10 Creators Update,Windows 10 Fall Update(very bad names). I work with the state agency and a lot of people come to me and say “What is Windows 10 Creator Update?????”
Give good names to Windows.
I want to ask the .Net team some questions:
Have you ever considered to provide desktop packs also for Linux and MacOS?
What’s your cross-platform UI solution? Is it Xamarin Forms? Or something else? Or none?
Xamarin.Forms already covers desktop: MacOS, Linux and Windows (some in preview state).
Will a Windows Forms app be able to use the Acrylic APIs on Windows 10? I mean, look and feel a first-class citizen on Windows 10?
I second this. Vista Dwm doesn’t work in Windows 10.
I third this. Winforms controls are way better and more fully-fledged than XAML
So now only “some” .NET core apps will be cross-plat. This is pretty silly, IMHO. This completely changes the definition of .NET core that we’ve all come to know over the past few years. It was all about simplicity and portability. Now .NET core is on it’s way to becoming just the next iteration of Microsoft behemoth dev platform.
programmers and developers need XAML and WPF in Cross platform .net core. there is no new Future i think we can use.
Indeed it is! I look foward to the day when .NET Framework comes in with CORE 🙂
Awesome work @.NET Team !
At last, my dream is coming true. Thank you Microsoft.
You have some weird dreams buddy!
Hello Microsoft Team and .NET fans. Some thinks from my mind.
@question to Microsoft : Did you consider to open Source some of your GUI System? So the Linux People can try to adapt WinForm etc. by themselves. I really think they could do it since they bring many great stuff in this world. ^^
@To all the Linux People who want .NET GUI – why you want UWP, WPF and WinForm to Linux? I think it is a huge step and cost a lot of time and Software developer. Did you look at https://github.com/aspnet/Blazor? Blazor will be a C# Framework for Client and Server side Code. If you take Electron.NET and Combine them (to Blazortron.NET lol) –> Linux Desktop App. I think Microsoft should spend more time to this – so we all get a new .NET GUI stack for all systems. An alternative would be https://github.com/praeclarum/Ooui –> funny Name and transform Xamarin Forms to HTML pages + Electron.NET –> Desktop app. Why we Need WPF?
@To Microsoft again : thanks a lot for ML.NET. This is exactly what I was hoping for. Finally .NET developer can enter the big data world and thanks a lot you do not Forget famouse Frameworks like ACCORD.NET! If you push ML.NET for data Analyse and Blazor for visualize .NET developer can be really proud to be .NET developers. Maybe you could consider to C# use Javascript Lib plotly to use from Blazor for plotting Data.
All in all – a big thanks to Microsoft. I am missing GUIs for Linux also but I know that with Blazor there can be a day where we developer really all can say “.NET – any developer, any app, any platform any app, any platform”.
You may want to check out: https://github.com/AvaloniaUI/Avalonia
hey they developed well. Nice thanks ^^ I did not know they reached beta.
So here you guys were all excited to bring us this fantastic news, and from the comments here, the reaction on average is.
THUD.
ZERO EXCITEMENT.
Here’s a suggestion, actually read the feedback.
Signed,
Microsoft developers endlessly waiting for a cross platform store
These developers have no idea what is entailed by this. Either you have something very close to native UIs (like WPF/Xamarin.Android/Xamarin.IOS…) or you have a wrapper that is very general but less performant (like Xamarin.Forms). You can see that Microsoft already has both approaches alive in Xamarin. I think these endlessly waiting developers are looking for magic that does not exist, without understand any of the tradeoffs of cross-platform approaches.
Those developers apparently had ZERO problem with Silverlight performance. If you’re unfamiliar with Silverlight, it was a high performance cross platform UI based on XAML. That is until Microsoft decided to completely screw over their developers, discontinued it, and decided to waste a ton of resources on stillborn projects like UWP.
We have some hybrid WPF apps that interop with (hosts) MFC UI via C++/CLI. Is that within the scope of the above .NET Core 3.0 story? Are you planning to support this scenario with 3.0?
Same situation here. Would love a perspective on this.
Very exciting news!
Does this mean we can now write our own WinRT components and use them in a WPF app?
We have a WPF app that interops with (host) MFC UI via C++/CLI. Is this within the scope of .NET Core 3.0? Are you planning to support this scenario?
I would like to ask a question that may have already been asked. This is because the Mono project has already put a lot of effort and work into implementing the Windows Forms classes to make them platform independent. Couldn’t we just continue working with these classes and add controls that are still missing and so on? I have to agree with all the comments here that it would be very good if Windows Forms and WPF were published as open source in any case. Even if Microsoft is not interested in publishing these components platform independent, the community could knit something based on the source code itself, perhaps with the support of the existing mono classes.
In my opinion, WPF would be much more important than Windows Forms. Especially since there are some very cool concepts here that should be available to the general public. In the last .Net versions hardly any adjustments were made to it anyway. It’s really time for the community to have the chance to intervene based on the source code.
I came here to ask the same question – why not push Xamarin Forms harder instead of doing this.
I would like to ask a question that may have already been asked. This is because the Mono project has already put a lot of effort and work into implementing the Windows Forms classes to make them platform independent. Couldn’t we just continue working with these classes and add controls that are still missing and so on? I have to agree with all the comments here that it would be very good if Windows Forms and WPF were published as open source in any case. Even if Microsoft is not interested in publishing these components platform independent, the community could knit something based on the source code itself, perhaps with the support of the existing mono classes.
In my opinion, WPF would be much more important than Windows Forms. Especially since there are some very cool concepts here that should be available to the general public. In the last DotNet versions hardly any adjustments were made to it anyway. It’s really time for the community to have the chance to intervene based on the source code.
Very exciting news!
Does this mean we can then write our own WinRT component and use it in an WPF application?
Is this going to be “The most pointless .Net Core release ever?”. Why’s the point of WPF for .Net core if it won’t be cross-platform?
WPF was originally designed to be platform independent, it still has lots of platform abstractions internally, does not depend on windows things directly (IE: handles), DirectX is abstracted, Windows are abstracted, the input is abstracted, why not continue this work and make it cross-platform?
No to mention this is a direct promise violation of the cross-platform promise, no matter how you twist it, this really smells like the old Microsoft way, EEE …
The amount of backlash you’ll get for this will destroy the developer faith in you, and all the open source effort you’ve put so far.
You’re absolutely right
@Eric,
Is the net core performance improvement added value?
On the server where it can increase throughput tenfold or lower costs, “hell yeah!” I’ll take it any day.
On the desktop where highly complex WPF app (yet carefully optimized) averages 3% CPU usage with rare spikes to 10-20% CPU usage on low-end CPUs, where switching to .Net Core will lower the average to maybe 0.5% and spikes to 10% the performance benefit is more like “whatever” …
Yes, .Net core has performance improvements, are they relevant on the desktop? I’d say “hardly”, considering WPF has been tuned and optimized over time, gracefully handling any complex UI applications by now (IE Visual Studio, 3D Max, etc). Are the perf improvements nice? yes, are they enough to warrant all this effort, no! They have to be more!
P.S. I’m one of them paying customers “and” part of the open source crowd (There’s no separation most of the time)
P.S.2 Vulcan is “more than capable” to handle a DirectX 9 level job, with ease …
Is winforms going to have the ability to compile to Web as wisej or visualwebgui does?
The “backlash” is mostly the usual “open source my stuff” crowd that are talking their book and not necessarily representing actual paying customers.
First, there is a big point in preserving millions of dollars of existing and ongoing investment in WPF applications worldwide for existing Microsoft customers, and allowing side by side deployment and all the other benefits of .NET core. This in itself is more than enough of a reason.
Second, there is still nothing that prevents open sourcing or porting WPF or WinForms in the future and this announcement is inherently synergistic with such a strategy.
Third, DirectX is not just a minor detail that is “abstracted away” but is a huge piece missing in Linux/Mac which would be a massive undertaking to re-implement. Vulkan wouldn’t cut it.
Is the net core performance improvement added value?
On the server where it can increase throughput tenfold or lower costs, “hell yeah!” I’ll take it any day.
On the desktop where highly complex WPF app (yet carefully optimized) averages 3% CPU usage with rare spikes to 10-20% CPU usage on low-end CPUs, where switching to .Net Core will lower the average to maybe 0.5% and spikes to 10% the performance benefit is more like “whatever” …
Yes, .Net core has performance improvements, are they relevant on the desktop? I’d say “hardly”, considering WPF has been tuned and optimized over time, gracefully handling any complex UI applications by now (IE Visual Studio, 3D Max, etc). Are the perf improvements nice? yes, are they enough to warrant all this effort, no! They have to be more!
P.S. I’m one of them paying customers “and” part of the open source crowd (There’s no separation most of the time)
P.S.2 Vulcan is “more than capable” to handle a DirectX 9 level job, with ease …
“Third, DirectX is not just a minor detail that is “abstracted away” but is a huge piece missing in Linux/Mac which would be a massive undertaking to re-implement. Vulkan wouldn’t cut it.”
You mean like the code THEY ALREADY HAVE. Both the Xamarin team and their Silverlight repositories have plenty of code for rendering XAML on those platforms.
May I ask, what are the benefits of porting a WPF business application to .Net Core 3? What can I tel my boss? Thanks
“For new desktop applications, we’ll guide everyone to start with .NET Core 3.”
I know you’ve announced .Net 4.8 in this blog, but what does this mean for the longer-term future of .Net 4? Will there be a .Net 5, or should we be considering migration to .Net Core if not in the short term, then certainly in the medium to long term.
I realise that .Net will be supported for many years yet as a core part of various OS versions, but would this support be runtime only where dev tooling is wound down. What I’d want to avoid is a Silverlight-style death, where Microsoft dropped Silverlight with (at least as far as I can see) no formal announcement that development had ceased.
If the future is .Net Core, that’s fine – I have no problem with this – the sooner we know, the sooner we can look at how to migrate.
Why not spending all efforts to concentrate on one cross platform UI Technology.
I cannot see any much Progress in XAML Standard which should be the way to go ahead!
Will multiple versions of .NET Core runtime be able to coexist in the same process? For users with multiple Excel addins where different addins uses different versions of .NET Core for example. Or would that be a case where we have to continue to use .NET Framework?
As someone who’s had the misfortune to use WPF for the last four years I’d like to say how disappointed I am to learn that Microsoft have decided to resuscitate this tired old beast, thereby giving my employer a good financial reason to never migrate away from the painful legacy world of WPF.
Word
I understand your business. You understand mine when I choose AvaloniaUI.
Very exciting news!
Does this mean we can now develop our own WinRT component and then use it in an WPF application?
Being WPF dedicated developer since its introduction – I find UWP the best UI platform. There are missed in UWP certain controls (Charts, DataGrid), which makes it harder to sell it in banking projects – nevertheless UWP is the best of Microsoft UX shop. I prefer to see WPF being bent to follow UWP model. Microsoft shall put more constrains on UI vendors preventing them from dragging Windows Forms libraries into WPF platform. There shall be more detail certification process for UI vendors. .Net Standard is great when introducing more rigorous compatibility among different UI models.
I suppose this also means I can use the new SDK project system with Windows Forms applications and target .NET Framework 4.x? This would be great news for me, as I have to work on legacy Windows Forms applications a lot (and merging the old format, well, is not so nice).
Is there any news on System.Drawing for .NET Core 3?
System.Drawing is already part of .NET Core 2, you can find it on NuGet as System.Drawing.Common. Hope that helps!
Question: Core 3.0 will include native compilation for managed code? This will be really useful for desktop apps.
I too would like to know if this is what we get.
Omg this means that the synchronization context is back ? or worst, all of them ? I’m scared already 🙁 I was really happy that net core was free from that curse 😀
Happy to hear that we will now be able to take advantage of the UWP WebView in WPF apps. Unfortunately, without Edge support in Windows Server we still won’t be able to move away from the legacy WebBrowser in our enterprise environment. Any plans to bring Edge to Windows Server?
Why Windows Desktop App ? Where is the web in all this ? A GUI to develop apps for the web using XAML + C# ? Where is it ?
I thought the future was the WEB. I’m lost !
Add your vote here, @GearWorld… quickly approaching 10,000 votes:
https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/10027638-create-a-ubiquitous-net-client-application-develo
Over 300 in the last day. 😉
People use desktops when they sit down, and mobiles when they move. Desktop and mobile apps are very important, and the less they are based on web technology, the better they will perform.
IMHO the biggest problem is MSFT is asking the wrong peoples for theire opinion: There is a whole army out there of developers working on – and being held responsible for – all kind of LOB applications. In their world, a bug makes Millions go down the drain, holds up a production line or in my case can harm peoples physically. Those devs can’t flock from Conference to Conference on their employers expense. They have actual work to do, which has to be accounted to paying customers. They built the foundation of MSFTs success.
But MSFT tends to address what they call community to get future directions. And most of this community has obviously (paid) time to fly around the world, discuss github issues and blog entries and report bugs for expensive paid VS products. But they are not involved to projects running and maintained for years, and were every minute of work has to be justified in front of paying customers. So they go easy with advocating rewriting code every year to follow the current direction of MSFT. They tell us to for example drop WCF and rewrite working and tested code to use what’s currently the big thing. Why would a customer pay for this? The best she can get is not much bugs introduced. Just to port it again to waht’s considered the next cool thing in 2 years.
So if MSFT wants to know what all the devs using the expensive cooroarate licenses need, they should stop asking kool aid kids. They are free to think what’s cool, as most of them do not have paying customers for. Net projects anyway. They just enjoy being part of what MSFT calls community. Nothing wrong with that, but MSFT should note ask them for advice. It’s the wrong audience.
Of all comments made so far (173 atm) this is the one I can wholeheartly agree with. When I tried to discuss these news with my fellow colleagues today all I got in return was some head shaking. Microsoft’s developer story is no longer met with excitement but rather with a sense of anxiety that they might deprecate something important again on their disoriented quest for the new cool. It’s a sad time to be .NET developer who actually has to make real LOB-software for real customers and who doesn’t have time to rewrite “Hello World!” for the 1000th time. I still remember the days when Microsoft’s motto used to be “developers! developers! developers!”; today it is the “Our strategy has shifted”-company.
Nodding my head as well. There have been probably a dozen posts like these over the past several years and all these words do not amount to much quantifiable metrics. Please consider joining a very grass roots vote (well *I* feel it’s “grass roots” and I made the sucker) and add your numbers to a movement. It’s really the only power we have outside of whining in the comments of these posts and pray that someone listens and can do something about it. 😉 You can’t lie with numbers. We are now 300 away from 10,000 with 2.5 years under our collective belts:
https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/10027638-create-a-ubiquitous-net-client-application-develo
I’m not so sure about this. The kool aid kids weren’t asking for Windows Forms as far as I know 🙂
Right, no one asked for Forms on Core 🙂
But the small but loud .Net Core “community” still tricks MSFT into believing they would use .Net Core for green fields instead of what’s established in the web space. But they don’t and won’t. Because their is no paying demand nor devs to hire.
The day MSFT is clearly and reliable communicating if .Net Core 3 will be usable on Win7, which of our numerous dependencies beside the Forms/WCF is going to be available, what we are expected to do with our investments in COM, WCF, C++/CLI, NT services etc is the day I start to believe MSFT listens to us instead of the kool aids.
Because new and cool is not what convinces our customers to pay for dev hours.
Or to put it harsh: The only reason to use MSFT technologies today is saving existing investments into MSFT technologies. Everywhere this is not required, devs and customers have abandoned ship years ago. And they wont come back.
This is so true. Anyone who says “why don’t you use WebAPI?” when designing an enterprise solution is either stupid, has infinite funding, or lack the experience to actually know what the result would be a few hundred thousand lines of codes later. Development time does matters. Not everything is a public http API, using something like protobuf solves one thing, WCF solves a shitload of more problems.
True, in reading the WCF responses, I got the feeling that the commenters had never written anything serious behind the firewall. Certainly they never had to make a team of people with a wide array of abilities/proficiencies consistently productive in an enterprise situation.
Great comment Joerg, I agree with every line of it.
To write a huge, serious LOB app, you need an army of lawyers, economists, business analysts… You have to wait for approvals, to get certificates if you are working for the government, and as you know… their working hours are not free. Development and testing of such an app can last for several years!
So LOB developers want something consistent, they can rely on for at least a decade. Cool kids are cool, but even their salaries are payed out by some of these boring old apps. You cannot rewrite these apps every 6 months, or even every 6 years… In LOB, forms over data apps, good old .net is the technology to use.
So using .Net Core 3 will I be able to add a UWP MediaPlayerElement control to the Children collection of a WPF Canvas container in a WPF project? So this: wpfCanvas.Children.Add(uwpMediaPlayerElement);
If so…
Will the MediaPlayerElement obey a 45deg RotateRenderTransform placed on the WPF Canvas (for example) and…
Can I place a WPF label control over the top of the UWP MediaPlayerElement, having a 50% Opacity property value, so that at run-time I can see the contents of the rotated MediaPlayerElement e.g. a playing video behind the semi transparent label at run time?
In other words does this mixture of UWP and WPF controls all render correctly and obey the designed Z-Index layering applied within the WPF project?
Will this make it possible to write a Windows Service using .NET Core?
In .NET Core 3 can I will create my models without needing a separate project?
I really hope this transition will finally help to move WPF further, it’s a shame to see such a great technology stagnating over the years. The first step could be the long-awaited support of the “infamous” XAML2009.
While quite clearly the desktop packs for UWP/WPF/WinForms are Windows-only, will .NET Core 3.0 on Linux be able to build projects that reference them?
What are the chances of seeing Microsoft Fakes supported with .Net core? Or, maybe, a couple of Microsoft resources to help Toni Solarin-Sodara get Pose to some usable state (https://github.com/tonerdo/pose)?
Lack of Fakes for .Net core has been a significant set back in testability of the code.
Also, being able to collect code coverage on Linux would be amazing
Excellent news, especially that their will be no coding impact ? As we support both desktop and web based applications in a VB.NET environment, we need this moving forward
Does this mean that the dotNet framework will become Unnecessary?
Dose this mean that the dotNet Framework will be an expedient thing and will come to an end?
This is awesome news. Thanks for finally doing this, guys! It is one step closer to being able to deprecate .NET Framework and get all of .NET onto Core.
Please answer honestly. Is this deliberate act of embrace-extend-extinguish?
Been developing on .Net for years. Just moved to .Net Core for all my greenfield work BECAUSE it was cross platform.
(LOTS of stuff to relearn and try to get working, but worth it I thought for the future benefits)
This announcement says to me that Linux is now a second class citizen in the .Net Core ecosystem. You can wrap it up any way you like in terminology. (Plugins, option packs…whatever)
The fact is, the .Net Core team is dedicating resources to a windows only product in an ecosystem which is cross platform.
Pretty shattered actually. Could have used those same resources to value add to the cross platform community.
It seems every time I finally trust Microsoft enough to embrace a new technology they burn me again and again.
I don’t think I’m alone on this. No one I know is porting their existing stuff to .Net Core. NO ONE. Not a single one.
I’ve just had to learn the ‘.Net Core Way’ of doing things for greenfield stuff, so why not go the whole hog and throw in a cross platform UX layer. NO ONE is going to try to port any of our legacy stuff to it, so why not use all of those resources at Microsoft, who are currently tied up doing windows specific packs for people who are never going to use them, to write a simple, cross platform UX?
Probably could have had it done by now…just saying
Microsoft is a small company with limited resources.
Please consider adding in your 3 votes here towards a “whole hog” cross-platform UI, @Rubble:
https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/10027638-create-a-ubiquitous-net-client-application-develo
hope silverlight come back with .net core 3 on all platforms
Are are asking for this here, @jeff:
https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/10027638-create-a-ubiquitous-net-client-application-develo
There is also this vote as well. Combined they are over 15,000 votes. All these words on this blog fade but the numbers on these votes stay. Please add your votes to have them count… over time. 🙂
https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/5042512-open-source-silverlight
Any hope for WCF getting the same treatment of WPF?
Something like making the service hosting bits available on .NET Core but Windows only?
I am stuck with Windows 7 for years to come and I really appreciate that WPF is finally getting some netcore support.
I’ve been really frustrated with lacking support when you try to use f# with WPF. Things seem to be finally improving somewhat. Thanks. 🙂
I will also be developing WPF applications for Windows 7 in F# for years to come. Solidarity, brother!
Hey! Have you tried Elmish.WPF? Makes WPF + f# much more fun.
Well, and please, after this, you should port web forms!
So, will .NET Core replace .Net Framework eventually ?
That’s exactly my question. Why WPF stuff has to go into .NET Core to be only bound to Windows platforms, when it was happily living in .NET Framework all that time and no-one complained. This will not make WPF cross-platform, so why bother.
I think the only reason is that .NET Framework is monolithic. This prevents efficient re-use of .NET Core 3rd party/open-source libraries, specifically created for .NET Core. The next logical step will be to kill .NET Framework altogether, and replace it with more modular .NET Core.
That’s probably where it’s all going.
Exactly, it makes no sense to use WPF with .NET Core if it is going to run only in Windows, we have this already! It is a waste of time. This roadmap is like a very bad nightmare.
Regarding “maximum isolation” and “shipping .Net core with your app”:
What is the difference between what is described here for .Net Core 3 and a self contained executable as described for .Net Core 1 here: https://www.hanselman.com/blog/SelfcontainedNETCoreApplications.aspx
I was hoping for supporting .Net Core on more platform like mobile and consoles.
So even with version 3, the only true cross-platform target (desktop platforms actually) is good old console apps.
I think it would’ve been better if you added all these goodies to Mono instead.
Few questions went unanswered…
1) Will Windows services be supported with .net core 3.0?
2) what is story/update on “self-contained exe” for .net core
3) update on CLI -native switch
4) update on LLVC for CIL
5) update on WebAssembly / wasm based off CoreRT
I would love to see bindings for GObject Introspection (GI) in .NET Core to able to use widget toolkits such as GTK+ in order to develop cross-platform desktop applications for Windows, Linux and macOS.
The real game-changing would be GDI+/Winforms rewritten for Directx.
Check DevExpress, they are doing exactly that with their components. The DirectX grid speed is fabulous.
@COBRASoft: Is this really true? I didn’t know about this. If they really do, they need to have wrappers around DirectX? But I guess they are not using SlimDX or SharpDx, right?
Does this mean that we loose the simplicity of win forms and will now have to forgo w informs development finally be pushed into exam?.
Sooooo, when can we expect something like Ooui.Wasm, .Net/XAML in the browser?
http://praeclarum.org/post/171899388348/oouiwasm-net-in-the-browser
Vote for that here, @Brett:
https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/10027638-create-a-ubiquitous-net-client-application-develo
Closely approaching 10,000 total votes. You (and I) are clearly not alone in our thinking here. We’re actually the top requested ask in all of Visual Studio and any other MSFT UserVoice in the entire ecosystem, as far as I know. I am not sure of one with a greater vote count. So please add your 3 to the pile to help send the rather unmistakable message at this point. Thank you for any consideration!
Groovy! Will do! Very excited about web assembly and future .Net integration in the browser 😀
This is very strange strategy to make support for WPF and Windows Forms (sic!) on Windows. What’s the reason? Waste of time/resources IMHO. Please consider community opinion.
Great news. Get us preview builds sooner rather than later and do learn what discouraged early Core adoption. I’m pretty sure you have.
I’ll be hammering in the bug reports the moment you’ve got a preview out.
For desktops apps that incorporate Workflow will there be a Windows-only pack for running Workflow using .NET Core 3?
And what about desktop apps using WCF on Windows?
Reading between the lines here is seems like .NET Framework 4.8 and .NET Core 3 will not available on Windows 7. Or at least many of the features advertised will not be available.
Videos show Edge\UWP hosted in WPF, and this could potentially include Win2D. These technologies have no precedent in existing in Windows 7 having been built on Windows RT.
I would be amazed if Edge, UWP, Win2D all of a sudden was available to desktop apps on Windows 7 through Core 3 ‘packs’.
Microsoft should be upfront about the situation rather than vague suggestions that it ‘might’ happen or ‘might not’. Internally you must know full well what the situation is I don’t see the purpose in being abstract about it, it only feeds mistrust. For us developers who have to support Windows 7 it is frustrating to be told of ‘exciting announcements’ that later transpire to only be for Windows 10 applications. The same situation happened with “Win2D” at least they admitted straight away it was for UWP only. It’s like hearing “There’s an amazing new car you should learn about …….. only available in Japan”.
Do those desktop apps that are developed based on .net core 3 become one-core OS compatible? In order words, can those apps run on the non-PC windows 10 platforms, such as IoT platform?
If Microsoft wants to finally get people off WPF and onto UWP, all it has to do is make UWP run on .Net Core on Mac, Linux, Android, and iOS. Everyone will start writing UWP apps!
Avalonia is a XAML that runs on all these, is in beta, and works pretty well. It only took a few years to build so don’t give us this line about being “too heavily dependent on DirectX!”
I also thought so when started reading but that’s not the case, they didn’t do shit, but the islands thing.
WPF/UWP ain’t coming to Linux/Mac.
The article only says that you’ll be able to have a WPF app target .NET Core, not that WPF would be part of the .NET Core.
What a total disappointment.
Hosting one type of UI technology stack inside of another UI technology stack. Not necessarily the best way to get things to work for enterprise solutions needing to live 7+ years for business document retention purposes.
JS/HTML/CSS wrapped in a browser control inside of a WPF or WinForms application also error prone and risky for any 7+ year expected lifespan.
Trying to reuse bits of your html/js/css web site inside of browser control hosted in a desktop application or mobile application is overly costly and a maintenance problem.
Throwaway applications – which excludes most enterprise ones – excluded.
Watching Build 2018, it was interesting listening to the Twitter developers talk about how they designed their new Twitter App….what they wanted was “consistency” of their app on different devices/platforms, so they actively did not follow “native” conventions of each platform – their app is a PWA though….so has certain difficulties in operating offline, etc, and not being optimal performance wise (ok things are getting better in that area). Some users have devices in different ecosystems, and that do not want things to work/be located in different places when they switch devices. The “native” look people use the argument that “native” is best to criticize WPF and Silverlight, which use “Windows” conventions – I’d rather just call them conventions….the fact they originated from Windows is moot. However, for websites, they are quite happy to have “consistent” looking sites, that don’t alter/change to the “native” platforms look – so you have some contradiction there. The fact is a “consistent” UI framework that works the same on all platforms the same is very much wanted and needed – heck if “native” look is needed, then I’m sure the “templated” nature of WPF/Silverlight could help in that area, so providing the flexibility of the best of both. Silverlight was nearly the answer….it was just the plugin and restrictions imposed by various outlets (i.e. chrome, etc), that prevented it’s spread, and the way it was too tied/marketed trying to spread the “Windows” paradigm. Restart Silverlight, base it on NET Core, and get it running in the browser via WebASM, and/or natively on each native platform using .NET core as the base.
totally agree, web assembly also runs without browsers. Just like SL.
it is exccellent
Such a shame this is not coming sooner.
Our company has made the decision already that UWP is the UI of choice with everything needing to use this.
I am just in the process of porting our WPF application to UWP using the desktop bridge. Even though we cannot port the entire application over in one go, there is simply too much UI to move over in one go. This would have made the process soo much easier.
Our plan had been to have two applications and use app service as a relay to communicate between the applications to try and make the user think they are using a single application.
Trouble I have is that I need this project complete before the end of the year.
That is some awesome news!
If does not runing in Linux or Mac, no meaning for me to this addition
For me it looks like “Hey, we’ve got N wannabe cross-platform frameworks, let’s create new really cross-platform one! Now we have N+1 wannabe cross-platform frameworks.”
Is it possible to write cross platform GUI app in C# and some version of .net ?
Why important MS apps like Vs code and Azure storage explorer are built with Electron?
Feel free to vote for exactly this, @Antonio:
https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/10027638-create-a-ubiquitous-net-client-application-develo
We’re only 66 votes away from TEN THOUSAND NERD VOICES SINGING IN UNISON FOR THE POWER OF A CROSS-PLATFORM .NET GUI SOLUTION!!! WOOOOOOOOOOOOO!!!!
Guys, imo you’re screwing up the naming (again). .NET Core, as the name suggests, was supposed to be cross-platform essentials in many people’s eyes (hence so many comments asking in comments “does it mean that WinForms are coming to Linux?” deapite you denying it in the article).
Calling a set of (Windows Desktop) compatibility libraries after .NET Core is confusing. At the very least you should not declare them to be part of .NET Core 3.0 (keep the name “Core” just for cross-platform) and ideally invert the naming, e.g. “Windows Pack for .NET Core”
I remember those naming escapades with dnu, dnx, dnvm, core, standard, dotnet etc. all too well.
Don’t make the same mistake 😉
Hope this helps
The philosophy of .NET Core was always cross-platform and if article says that windows desktop application will be supported in net core 3.0 then that should be cross platform. Just to have few called out benefits like performance, self-contained deployment etc. it does not make sense to transit Windows desktop application to NET Core 3.0. Instead one should improve it in Dot net framework and make all the improvements. If I still have to use Windows to use WPF/Windows Forms then be it coupled with NET Framework only and not confuse with NET Core which is supposed to run in other two platforms. What is the bigger plan? Is there going to be some add-on package for Linux or OSx in future on top of NET Core to run WPF/Desktop app? In that case, it is going to be super exciting!!
It would be super exciting, but until management changes, it’s not going to happen. In the interim, the existing management will run a few polls, ignore the overwhelming feedback, and then run some more polls.
https://youtu.be/vymuwk0yXkg
Sorry but I’m a little confused and would be really grateful if someone could help me here.
Lets say I want to build a brand new cross-platform client-server “enterprise” business application within my company, from scratch, using technologies which are on the Microsoft Roadmap and considered “strategic” and not “legacy” then what are my options ? As far as I can see server platforms would include
* An ASP.NET Core Server written in (say) C#
* A node.js server written in (say) Javascript/Typescript
And client technologies include
* a Web front end written in HTML5/Javascript/Typescript/and perhaps using React libraries
* A UWP front end writen in XAML/C#
Three quesions
1. am I missing something or are there any other platforms which Microsoft would encourage me to look at ?
2. are all combinations of server and client above equally valid or do some “work together” better than others ?
Node.js + UWP
ASP.NET Core + UWP
Node.js + HTML5
ASP.NET Core + HTML5
3. Looking at the above 4 combinations which can use SignalR and which use vanilla Websockets without SignalR for real-time push data (indeed what is the difference between SignalR and Websockets ?)
many thanks for any help / advice in advance
Richard
I see this roadmap and… I start crying. We have a big chaos now and you are going to add even more chaos. Now, we are going to have 3 versions of Entity Framework! This is too crazy. Everytime a developer needs to find a solution and google for it, he is going to find tons of not compatible answers (like now, but increased).
.NET requires a very relevant developer to put some order in this mess.
Why 3? Hello …. there is just EF and EF Core. Simple enough. And if you start sth new – always take EF Core. Thats it.
I am completely disappointed that it does not have support for Linux and Mac, in our company we have several multiplatform solutions, for us it is useless and an incomplete framework
Please, abstract away and open-source all rendering-independent WPF code like XAML support, layouts, triggers, dependency properties, etc.
Everything except the actual rendering.
It would be great to use the same layout engine for in-game UI.
I’m sorry that I didn’t understand this writing well.
Is it possible to run wpf application on linux if i use .net core 3.0 and desktop packages?
(The content was deleted per user request)
nope – the whole .NET GUI System has classes which are just wrapper for the machine Code based Win-APIs. In theory you can use the classes on Linux but when you try to run their methods …. error : Win-API not found! So in reality : no way. But Microsoft is working on BLAZOR – which enable you to run C# Code on Client and Server side. Together with Electron.NET and you got a GUI stack.
… that doesn’t run on iOS, Droid, or Windows Store.
hm …. yeah you are right. i forgot. But i hope there are some other Tools converting html to gui lol
Great news! Please bring Forms/WPF to Mac/Linux!
Hmmm, I remember those days when I was so excited about MS being more open-source friendly and open sourced .Net Core. I was hoping this day will come when you can develop GUI truly cross-platform as Electron apps/QT/etc.
I just don’t understand motivation of management team that would decide that .net core gui apps only work on Windows. When whole idea of .net core is a cross-platform.
What a massive let down that direction is.
I like C# but when it comes to doing cross platform GUI.. is no professional tooling at all, just a bunch of half baked github solutions with no real documentations/examples let alone wide adoption and additional features. .. it’s like the only actual good alternative for doing cross platform gui’s is actually QT, and that requires using C++ although they will be officially supporting python.. but yknow that’s just not a nice a language as C# at all far from it really. .. its just a a mess really.
And I can’t think of anything more stupid than this .net core stuff being cross platform, but lets not support the other platforms at the GUI layer with a consistent GUI/UX …WPF and UWP and just Windows 10 is just so damn bad I don’t care for Windows only development anymore, it ended with WinForms for me. They must dreaming if they think people want this direction. And as for Electron eergh … I guess QT and C++ or JavaFX is really the only way sane way.. JavaScrap is being given way too much attention.
I have to add my voice to the choir singing the praises of WPF. It is a brilliant technology! Microsoft will do well in making it available on Linux. As others have stated, if you don’t want to do it yourself, open it up to the community to do it. I am sure there’d be many takers.
Come on Microsoft, WE WANT WPF ON LINUX! :-):-):-)
Vote for that very idea here, Gerhard:
https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/10027638-create-a-ubiquitous-net-client-application-develo
When i can see .net Core GUI multiplat.?
I want one assembly for Windows, Linux,…
Over 10,000 votes are asking the same question, Alexander:
https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/10027638-create-a-ubiquitous-net-client-application-develo
As a .NET developer(for 10 years), whenever I argued with my Java friends about two frameworks. They always won because, Everytime they would be like Java is Cross Platform.
With . NET core I thought that my dream of becoming Cross Platform, Full stack . NET developer would come true.. But, now I am thinking to give up that dream. Honestly, .Net ecosystem has become more of a mess (Xamrin, Core, Standard, Framework, plus hopefully they will add some more copy-paste libraries), more than Java is. I am thinking to switch to Java ecosystem and start from scratch.
And make the title of this post more clear. People come with too many hopes here…
What I don’t understand is why Microsoft is thinking of Windows here again. Wouldn’t it have been much better to support the existing “Avalonia” project and make it marketable? Thus a conversion of platform-independent XAML is already possible. I don’t understand why a solution is only being built here for Windows again, and not thinking outside the box. I think it’s a shame about Microsoft.
Very valid questions, questioner. 🙂 We’re talking a lot in this thread about this very topic:
https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/10027638-create-a-ubiquitous-net-client-application-develo
Whenever we encounter a new UI tech we announce in there. 475 comments is no joke. Just ask this thread. 😉
This is really bad, it’s only a cheap shortcut – .Net Core is not really cross-plattform without a cross-plattform GUI-TechnologyWPF.
We agree, Thomas. Put your words into numbers with this vote here:
https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/10027638-create-a-ubiquitous-net-client-application-develo
Use QT for UI and .NET Core for business logic
On Windows simply reuse the same Bus.Logic and attach it to different UI technology (I still use MFC or WinForms).
Windows here again? Why don’t Microsoft develop a cross-platform UI Framework on .net core? It’s disappointing.
Nodding along with your sentiment, ic720. Thousands of other MSFT developers have expressed their disappointment and desire towards a better MSFT GUI future here:
https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/10027638-create-a-ubiquitous-net-client-application-develo
Please make the summary element from the project get put in the nuspec file. I still have to manually copy this over everytime I build.
What a mess,. Net Core 3 part cross platform, part windows only, why do I need. Net core winform? To run on windows? I can use net 4.7, wast of time. Unknown road map.
It is kind of sad we are in 2018 and there is no good UI library (both C++ or C#) covering major OS platforms.
QT is very close to that but the amount of controls available for that framework is so small it is unusable for more complex projects and I see people reinventing lot of stuff from scratch.
I still think QT + .NET Core is very good combination. Separating GUI from core logic can be fun in some ways and allows you to abstract presentation part.
So, everyone complaining about lack of good Linux UI library please consider separating Business logic from presentation layer.
My practice is the following :
For Linux:
GUI = QT, Business logic = .NET Core
For Windows:
GUI = MFC (due to high performance), B.Logic = .NET Core(or full framework)
(The content was deleted per user request)
One step at a time, people!
“.Net core + Windows Desktop Packs” is the first phase to deprecate Windows .Net Framework.
Only after that, we can discuss about unifying the .Net stacks or cross-platform UI library.
A possible approach I can image is that, MS provide an unified/abstract UI programming interfaces; platform vendors (Qt, Gtk, etc.) provide implementations.
for example:
“.Net core + Xamarin Desktop Packs”,
“.Net core + Qt Desktop Packs”,
“.Net core + Gtk Desktop Packs”
@Rich, please tell us this is true.
Otherwise, i cannot make up another explanation for your roadmap.
People are totally lost out there.
So this means Oracle has more experienced developers that can produce cross platform Desktop apps using JavaFX, while you are unable to do it with .Net Core, or you are greedy and want to sell more windows copies ?
changing architecturally with this new version. We’ll continue to offer a great cross-platform product, focused on the cloud. http://www.rajsonsdesigns.com/
Microsoft has made a BIG mistake with .NET Core 3’s Desktop support (or general lack of it).
In doing so will alienate a large number of developers who work with Linux, Mac and especially Raspberry Pi devices.
The thought of running an existing WinForms application of a RasPi really excited me – then I read the full text and cried.
What is the point of running a .NET framework without a GUI on a RasPi? To build a web server? Really? There is NO benefit.
But add support for WinForms/WPF on that platform, and you will overnight create a massive marketplace for low-cost stand-alone ‘appliances’ which can control real-world hardware via the GPIO pins.
You haven’t missed the boat here – you didn’t even bother going to the pier…. ;-(
Why would I want to create (or upgrade) a WPF app in .NET Core 3.0 if it will only work on Windows anyway? Isn’t the point of .NET Core to get the cross-platform benefit? Why go to Core when .NET Framework already supports WPF on Windows?
For example, I have an app, TorrentRover, written in .NET Framework 3.5 using WPF and C#. Why would I bother converting/upgrading to .NET Core 3.0 if I can’t get it to run anywhere new (Linux or Mac)? What’s the point?
So you can make use of all the APIs & UI elements that a UWP app has to offer in Windows 10 For example, toast notifications, fluent design, background tasks, etc. While there is a nuget package to utilize some of the UWP APIs in WPF, it is still missing a lot of features.
Personally, I am super excited for this since I already have a WPF app in the Windows store and being able to use UWP controls (like engagement tools/feedback hub, fluent design, & hopefully advertising) is a game changer in my opinion.
Please read blog- https://azuredevopspaas.blogspot.com/2018/07/blog-post.html
We need a fast and reliable UI framework for desktop. WPF is great and realiable but performance-wise is simply not usable in many desktop escenarios. Windows Forms is fast but old and UWP is just between. Why is it so hard to come with a proper API that we can use to develope great looking and responsive apps without having horrendous performance issues?
Please port asp webform !!!!!
Wow! COOL
I have a question about the DataGridView control. In the past it had specific support. It is still used. Is there still specific
support? I have reused one in a special way, i.e. in an eigensolver, with matrices. I just need to know whether to
use other means like WPF. That is, whether the DataGridView control is to be replaced.
My ten pence: “Cross platform” doesn’t just mean Windows / IOS / droid.
It means older versions of windows (7) , not just 10 “Creators edition / Fail update / thanksgiving release
Older XBoxes (My 360 is probably about to throw a RROD after I post this)
Phones – my Lumia 920 is fine, but its Windows 8.1, not supported, dropped as was Windows Phone 7 a year or so before I bought the Lumia.
Embedded kit (Arm etc).
For IoT devices, we have Win 10 IoT edition – which requires us to write UWP apps – even if the device has no UI, or at best a 40 character LCD display.
Later this year, we’ll have Azure Sphere OS – I’m still trying to find out if we’ll be able to code in C# – it has a Linux core, so I’m guessing C++ only.
The reason MS is dominant in Enterprise is that they used to sweat blood for backwards compatibility. Now they drop support like I drop my socks, and adopt the latest shiny new thing, like the rest of the Open Sauce community. How many javascript frameworks are there now?
The NEXT BIG THING is going to be WebAssembly – I think the Future Decoded app last November was something of that
ilk, some very strange effects on my Surface with dodgy WiFi. It got VERY hot, I think it was trying to phone home to report the dodgy WiFi (over the dodgy WiFi).
I have a MS Wireless Display Adapter , which allowed me to cast our PC desktops to the big screen TV. It no longer connects, possibly it needs a software update, which I can’t apply because it needs to be (wirelessly) connected to the management app on my Surface… It has a USB connector, but its is just for power, and I can’t plug it in the Surface directly for software updates.
There seem to be a lot of self-inflicted foot shots in Redmond these days. In my past life at EA, we used to joke about corporate decision making: “Ready, Fire, Aim” – uh-huh.