The Most Exciting Promise of .NET 5

odalet

Winforms/WPF: I know it is - work in progress, kinda, supported with .NET Core 3.1, however on Windows only. Are you saying it will be supported on Linux/Mac as well with .NET 5?

Alex Dresko

Are you low on hard drive space? Please explain why file size is a problem, not why it’s different from what you’re used to.

Xileer

I do development on extremely low-spec systems (Think <1GB total HD Space / <128MB Linux Deployments) so every KB counts. The Mono installation on Linux gives us a large enough shared code repository that multiple .NET Framework applications remain viable (The entirety of Mono is <5MB) and .NET development remains significantly faster than C++ development due to such.

Peter Adam

He spoke about SSD space, and yes, we are low on them.

Xileer

I made multiple edits post-submission so it’s understandable that that section was missed in the initial reading.

Peter Adam

But at least have mercy and do the GUI in something Windows-native.

Xileer

(Psst: Mono on Linux is a thing. Missing a few things - Sure - But it’s still definitely viable)

José

…or Mac-native. :slight_smile: The Windows interface next to the Mac is stupid! Microsoft can suck it, take a look the filename https://www.youtube.com/wat…

Joseph Adams

Not to my knowledge. They are wrappers around GDI and DirectDraw respectively, and neither of these are being ported. This does leave a gaping hole IMO in terms of the cross-platform desktop app story. But, really, I think the logical direction is that even desktop apps are going to be built going forward using Web technologies. Winforms and WPF probably exist only to support legacy Windows desktop apps.

José

Android is on its way… Bye Microsoft

odalet

That’s exactly what I suspected. In a way the article is a bit misleading in not mentioning that.
Concerning the trend toward web-based techs for desktop apps, sure there’s a trend: electron, blazor, webassembly… but I happened to play (only a bit) with Avalon UI. Seems something that could really replace WPF to me.

Mike

LOL You must be kidding right? Until the Oracle and Google supreme court case is over, I don’t see anything like that even being possible. Even at that point I don’t see it happening.

StealthTech

I agree with the legacy part of it. The move is to Xamerin or web technologies.

There is Xamerin.Forms GTK# (kind of)

GTK# Platform Setup

WOBFIE

"nullable reference"? Sorry, even don’t mention this sh**t. We don’t need it. It made for indian monkeys to stop 'em making silly mistakes. We’re happy with C# 7.0 and have no plans to move on Core. Core is dead born child, born too late. MS had to think first when they made “Windows only .NET virtual machine” (I know, sounds like idiocity, but MS made it). Now we have tons of code and no any wish to port it to run… again on Windows. Sorry, MS but you’re morons who waste YEARS on a limited technology. Now we used to it and there is no reason to move on Core.

WOBFIE

Study at last how to spell it! XAMARIN.

WOBFIE

Android suxx for years. After WPF, development for Android looks like driving a horse after automatic car. I’m not surprised shmoogle has plans to abandon this “side library above the Linux”.

WOBFIE

Show me your “cross-platform” apps, dude! I promise not to laugh very long! :)))

Immo Landwerth

TL;DR: it’s because Windows has no special handling for .NET Core.

On .NET Framework, your EXEs aren’t really EXEs. They are more like managed DLLs. When Windows starts a managed EXE, the OS finds & activates the correct .NET Framework runtime. The runtime then calls into your entry point (AFAIR this loader lives in C:\Windows\System32\mscoree.dll).

For .NET Core there is no OS provided loader. Instead, we deploy an EXE with native code which will find the correct .NET Core runtime, activates it, and then calls your entry point which sits in a class library next to it. The size of this native exe is ~180k, which is the fixed overhead you’re observing.

Immo Landwerth

We’re closely working with Unity. They already adopted .NET Standard and they plan on moving to .NET 5++ eventually as well.

Immo Landwerth

I’ve tried to explain our reasoning here: https://github.com/dotnet/c…