Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yeah, they have managed to solve the confusion over the various flavors of .NET in the best way possible, it would seem like.


I don't know about that. I thought I kind of understood the mess of the .net framework until now but now I am really lost.

Like asp.net core was meant to be incompatible with .net full framework because of inconsistent featureset, is that going away? For applications, .Net core binaries are different from .net full binaries, they compile to a .dll, not an executable .exe, you have to run them with a command line (and if you choose the option to create an exe it comes with lots of additional binaries that aren't required in full .net framework, plus I understand some additional problems of version compatibility with the installed .net framework). So is .net 5 going to be one or the other? Or is .net 5 just another way of saying that they are discontinuing the full .net framework and that now everything will have to be .net core? But then is a simple full .net framework 4.7.1 .exe run on .net 5?


Like asp.net core was meant to be incompatible with .net full framework because of inconsistent featureset, is that going away?

Just to add to the confusion, you can target an ASP.Net Core Application to run using .Net Framework.


Well I believe you can now, but I thought I saw a recent announcement that said it wouldn't be possible with the next version.

When re-reading the article, I think what they are implying is that they are ceasing support for .net full framework and just renaming .net core ".net". If it is the case it is kind of a big deal, there is ton of .net full code outthere, that no one has any appetite to convert. If it is not the case, are they going to rename .net full to something else?

This article does the opposite of solving any confusion.

[edit] there is a session in a couple of hours at Build, perhaps it will add clarity: https://mybuild.techcommunity.microsoft.com/sessions/77031#t...


They aren’t ceasing support. .Net framework is an integral part of Windows. It’s in maintenance mode. There will never be another major version of .Net framework - just security and maintenance releases.


.Net 5 isn't just a rename of .Net Core. Though for most people I think that understanding would be sufficient and not outright wrong, just incomplete. It is where Core takes over. It's also Mono to target other platforms, in a unified programming API.

Moving projects from .Net Framework to .Net 5 should be as easy or hard as it was to go from Framework to Core. In my case, this isn't a problem for the current project that I'm working on, but thankfully Microsoft will support .Net Framework 4.8 in maintenance mode for a very long time.


I think, for the most part, Mono is being rolled into Core. From what I've seen, it looks like large chunks of Mono were moved, migrated or otherwise refactored into Core anyway. My reading of this is that what is now the Core runtime, will be what is .Net everywhere, and that while not mentioned, Mono as a separate runtime, much like .Net framework will not see new releases in favor of a single .Net 5.


They seem to indicate that both Mono and CoreCLR runtimes will be maintained and available with different focal use cases as part of .NET 5.


Hardly.

They are achieving this by bringing Mono more "in-the-fold", making it interchangeable with CoreCLR, and ensuring CoreFX runs on every runtime.

It seems that are leaning on Mono because of it's AOT abilities, which doesn't say good things about the future for CoreRT.

I like the idea of using Mono though, it's easier to embed in native applications.


I think making Mono and the existing .NET Core runtime 'runtime options' simplifies the confusion a lot. Unifying the standard library was already a good idea, and had been partially done anyway. The existing Mono version of the stdlib was a good effort that historically hasn't stacked up when you try to port stuff (and incrementally had been replaced with chunks of the 'you can look at it i guess and it's sort of like desktop netframework' reference sources).

I'm personally happy to see more of the .NET Core stuff end up in Mono since it usually is battle tested and has better compatibility, and I'm also happy to see more stuff approximating the existing .NET Framework and Mono workflows since .NET Core has historically been unable to do important things that netframework and mono can do.

bias disclosure: I work on Mono


The article mentions that while MonoVM's (LLVM-based) AOT efforts are ahead, CoreRT has outpaced MonoVM in JIT performance, so CoreRT will still be the default in everything but iOS and Blazor which are the only two 100% AOT platforms.


If you aren't doing AOT, why use CoreRT over CoreCLR?


Sorry, I meant CoreCLR there where I wrote CoreRT. Got the acronym confused briefly.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: