Hacker News Reader

Comment by benaadams | Hacker News Reader

For server on Windows, Linux and MacOS you'd probably sway .NET Core.

For client on Windows, UWP is .NET Core, and WinForms or WPF currently .NET Framework. Though .NET Core 3.0 is meant to bring the full set of Windows UI stacks to .NET Core https://blogs.msdn.microsoft.com/dotnet/2018/08/08/are-your-...

For Tizen you'd also use .NET Core

For client on macOS or Linux you use Mono

For games you'd probably use Unity (Mono based)

For iOS, tvOS, watchOS, Solaris, Android, Solaris, IBM AIX and i, BSD (FreeBSD, OpenBSD, NetBSD), PlayStation 4, XboxOne, WebAssembly you'd use Mono

Can still use Mono for client on Windows and the ASP.NET Core stack is quite happy running on Mono on the server; but they have different focuses.

If you were building a library you'd target the .NET Standard 2.0 "contract" and it would cover all the runtimes.

View on HN

> For client on macOS or Linux you use Mono

I’ve been using .NET Core 2.0 and now 2.1 on embedded ARM Linux. Works surprisingly well.

Hm, curious - why do you say wasm and XboxOne would lean toward mono? Doesn't Blazor target .NET Core? I would've assumed .NET Core w/ UWP would be first class citizens on XboxOne? Thanks in advance!

Edit: maybe I was confused about Blazor. Looks like it can work with ASP.NET Core, but the info I'm finding talks about building with mono.

I guess the more interesting question is, do you think Mono will remain important for the places you've mentioned, or will be replaced more and more by .NET Core? Especially given the UI goals with .NET Core 3 (and my own biased belief that .NET Core is the clear unabashed future of .NET).

For the WebAssembly client side Blazor it uses the Mono WebAssembly (though .NET Core on server) as the Mono compile chain for WebAssembly as it is the most mature implementation (also produces smallest output from their work on watchOS).

If you are using Blazor as a full desktop app (e.g. Electron) then you can use .NET Core on the client and that can talk to the javascript as a local server; but for running in the browser directly as WebAssembly it uses the Mono (WebAssembly) runtime.

XboxOne can run UWP and for that you can use .NET Core (via UWP) in a "shared" mode; however it also has a dedicated "game OS" mode (which most boxed/AAA games use) which takes priority over everything and has full hardware access, but that doesn't allow Jitting so you can't use .NET Core in that mode.

Mono and Unity have mature AoT compilers so can run in this mode (Xamarin also need AoT for iOS and Android which also don't allow Jitting, and Unity needs it for a lot of the platforms they support. Mono and Unity use different approaches to AoT though)

Mono is now sharing C# source code with .NET Core (and it goes both ways); but as far as I'm aware .NET Core doesn't seem to be rushing to fill any of the gaps that Mono serves well (iOS, Android, etc)

Though they are working on an AoT version of .NET Core for Windows/Linux/macOS https://github.com/dotnet/corert but that seems to be more focused on competing with golang and rust's AoT single exe offerings.

For desktop UIs; we'll have to see what's next :)

> For desktop UIs; we'll have to see what's next :)

I've been working on a project to bring GUI to .NET. I think it really is the best option out there.

https://github.com/pauldotknopf/Qml.Net

WASM (Blazor) uses the Mono runtime.

> I guess the more interesting question is, do you think Mono will remain important for the places you've mentioned, or will be replaced more and more by .NET Core? Especially given the UI goals with .NET Core 3 (and my own biased belief that .NET Core is the clear unabashed future of .NET).

I don't know what the future is for Mono. Mono currently has support for platforms that .NET Core doesn't specifically target - iOS, Android, native code through Unity, WASM, etc. It'll probably start to move toward specifically supporting those platforms while continuing to support newer versions of the .NET Standard.

.NET Core/.NET Standard is the future of mainstream .NET. .NET Framework is dead. I've heard it from Microsoft people directly. There probably will never be a 4.9, and there will definitely never be a 5.0.

> .NET Framework is dead

Surely it's not that dramatic?

I'd imagine at the least it would be in maintenance mode for years, although in principal I'm inclined to otherwise believe this. I don't think anyone was really convinced by the early talk of co-existence.

I'm pretty sure there will be updates that implement newer .net standard versions, but I doubt it will receive a lot of non essential upgrades for performance and such in the future.

Reply on news.ycombinator.com