Somehow I actually fell in love with .NET Core 2.0. While their naming is still confusing and it's hard to know what will come next. I found myself amazingly productive with Razor Pages.
It's really cool if you don't need an SPA and you could do everything pretty damn fast. It's like WebForms, but without the Microsoft specifics and instead relies on the good old html5 part to make an app great.
That graph is completely misleading then. I can understand why they don't want to show actual y-axis values, but at least put relative values on that axis. Even "60%" and "100%" would do.
Not a .NET developer, so apologies for the dumb question, but why did MS release a second open source .NET implementation around the same time as they acquired Xamarin? Do .NET core and Mono compete with one another? Do they serve complementary roles? Why would I choose one over the other?
.NET Core and Mono are not exactly analagous. A better comparison historically would have been Mono to .NET Framework (i.e. classic .NET).
.NET Framework is a fairly expansive set of standard libraries bundled with a runtime - it's commonly used and well-supported, and dates back to about 2001, give-or-take a beta or two. There's a lot of current and legacy applications built on this out in the wild.
.NET core is effectively a do-over for the longer term in the form of a minimal set of dependencies that imports more of the standard library separately. There's a couple of reasons for doing this - primarily the parts that have been abstracted out mean that .NET core runs in a lot more places than the classic framework (including natively on devices like the Raspberry Pi, for example), and can also be (and is) fully open-source (the classic framework is mostly open-source these days as it is, but licensing problems meant that not every part of the toolchain could be opened up).
There's also the question of expectations when it comes to community changes. .NET Framework was adopted in many quarters on the basis that it was developed by Microsoft directly, and bureaucratically opening it up to community changes after the fact becomes problematic due to the massive number of stakeholders and their expectations.
I'm sure someone else can add more info but as I understand it this is the gist.
.NET Framework was first, the major install on Windows only. Mono came after, to try and replicate .NET on non-Windows and with an open-source approach. Eventually .NET Framework code was open-sourced (at least read only in the beginning), which also helped Mono get better.
.NET Core was created to take the aging .NET Framework and rebuild for a faster, easier deployment, quick release cycle, and cross-platform on Linux and Mac OS; without hurting the decades of backwards compatibility.
Mono meanwhile became the base for Xamarin for mobile apps and Unity as a gaming engine. Even though Microsoft acquired Xamarin, Mono already had much uptake in both of these scenarios that it didn't make sense to attempt replacing it, so now we have Mono for mobile+games and .NET Core for the rest.
.NET Framework will still be around for a decade but is effectively retired and .NET Core 3.0 will fill in any remaining gaps for Windows apps that still need the full framework today.
My understanding is that Mono is being billed as a client framework (Monogame, Xamarin, Unity, Blazor) while Core is more for the server/systems target. To add to the confusion, ".Net Standard" is a library compilation target that should work everywhere (even the legacy Windows-only .Net Framework). Interestingly, the newly MIT-licensed Xenko game engine compiles to .Net Standard libraries which is how it supports so many platforms (via barebones launcher/shim projects for whichever framework implementation is desired). Edited for clarity, thx.
From what I remember reading a post or listening to podcast is .net core is "server-centric" and mono is "client-centric" also relative "foot-print" in size.
I'm a huge fan of C# and ASP.net, but this transition hasn't went as smoothly as I hoped.
I tried .NET core a lot pre-1.0 and it seemed really fragile (especially on Mac and Linux, which was my main excitement around it).
As I was a bit nervous about that, I started a new project in 'classic' .NET w/ MVC5. It however seems a lot of projects are migrating rapidly to .NET Core and leaving support for legacy projects recently.
It does seem to be a giant pain to migrate a legacy asp.net app to asp.net core (very manual). Anyone have any tools/advice on this process?
Porting to 1.0 was a pretty big headache, there was a lot of stuff in full .NET that wasn't in 1.0, and a lot of open source libs hadn't been ported yet.
In 2.0 they had a bit of a rethink about how stripped down Core was going to be and added a heap of stuff in, plus a lot more (most?) big open source libs have been ported. So porting legacy apps is much easier.
However I don't see any point porting a legacy app unless there is something in core you want. Perhaps you'd like to move your app over to running on Linux servers? At my previous company we ported parts of our product so that we could sell cross-platform support without needing our users to install mono.
I was an early adopter of .net core. It definitely had its quirks in the beginning. Recently I gave it another go, it's really improved a lot. Like it's production ready now. I'd say pick it up again.
It's stabile now. Just forget the alphas and 1.X ever existed. If you really want to get a hang of it, don't use Visual Studio. user VS Code, and the CLI tools:
I get the feeling that there has been a lot of low-hanging optimization fruit in .NET that went unaddressed because a) the original compiler was too complicated to change and b) there was no pressure to improve it because it only ran on Windows and there were no real competitors.
a) was addressed by Roslyn, which is apparently much more manageable, and now that .NET is supposed to run everywhere, it has to have competitive performance. Hence the big gains.
The first commit says "Vectorization of string.Equals". It now uses SpanHelpers.SequenceEqual. How is that vectorized when it's just an unrolled loop from what I see? Does vectorization not mean using SIMD instructions? It also means improving data dependencies?
Maybe there is an autovectorizer in the compiler that recognizes the shape of that loop and uses SSE to do it 16 bytes at a time instead of 8 at a time?
Bing is huge both in codesize and technologies used, but most of it is a flavor of Windows Server 2016 (soon 2019) + http.sys + C# + Razor + TypeScript for Frontend. C#/C++ for middle and lower tiers.
Definitely interesting... I think this speaks mostly to having a direct compile option for .Net Core that works well more so than the platform as a whole.
Personally, my first past at most things these days would be with Node.js simply because of productivity, but it's nice to see more options for performance growth as needed.
Years ago I spent a lot of time trying to convince some of our large bank customers that we could run their stuff on Windows NT instead of SunOS or AUX or whatever by noting that microsoft.com ran on NT. I'm not even sure if it was actually true at the time, now that I think about it.
They should have renamed .net to something else. Now we have to deal with the same issues as the python 2/3 but maybe even worst as it's harder to tell which apis are available looking at sample code.
Bing folks, are you running this on Linux? Common problem a few years ago was that perf of the Linux version of Core sucked compared to Windows. The only way to fix that is through serious dogfooding. I’m wondering to what extent Microsoft is committed to such dogfood on Linux.
Windows Server 2016. All the improvements in the post that helped us are the same on Linux. I will agree though there's more dogfooding to be done. It's happening slowly but surely.
[+] [-] merb|7 years ago|reply
[+] [-] magnat|7 years ago|reply
That graph is completely misleading then. I can understand why they don't want to show actual y-axis values, but at least put relative values on that axis. Even "60%" and "100%" would do.
[+] [-] mjsabby|7 years ago|reply
[+] [-] ericcholis|7 years ago|reply
[+] [-] Someone1234|7 years ago|reply
It is still awesome that the community can comment, and Microsoft does take community changes regularly for .Net Core, VS Code, etc.
[+] [-] matthewwarren|7 years ago|reply
[+] [-] sevensor|7 years ago|reply
[+] [-] headmelted|7 years ago|reply
.NET Core and Mono are not exactly analagous. A better comparison historically would have been Mono to .NET Framework (i.e. classic .NET).
.NET Framework is a fairly expansive set of standard libraries bundled with a runtime - it's commonly used and well-supported, and dates back to about 2001, give-or-take a beta or two. There's a lot of current and legacy applications built on this out in the wild.
.NET core is effectively a do-over for the longer term in the form of a minimal set of dependencies that imports more of the standard library separately. There's a couple of reasons for doing this - primarily the parts that have been abstracted out mean that .NET core runs in a lot more places than the classic framework (including natively on devices like the Raspberry Pi, for example), and can also be (and is) fully open-source (the classic framework is mostly open-source these days as it is, but licensing problems meant that not every part of the toolchain could be opened up).
There's also the question of expectations when it comes to community changes. .NET Framework was adopted in many quarters on the basis that it was developed by Microsoft directly, and bureaucratically opening it up to community changes after the fact becomes problematic due to the massive number of stakeholders and their expectations.
I'm sure someone else can add more info but as I understand it this is the gist.
[+] [-] benaadams|7 years ago|reply
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.
[+] [-] manigandham|7 years ago|reply
.NET Core was created to take the aging .NET Framework and rebuild for a faster, easier deployment, quick release cycle, and cross-platform on Linux and Mac OS; without hurting the decades of backwards compatibility.
Mono meanwhile became the base for Xamarin for mobile apps and Unity as a gaming engine. Even though Microsoft acquired Xamarin, Mono already had much uptake in both of these scenarios that it didn't make sense to attempt replacing it, so now we have Mono for mobile+games and .NET Core for the rest.
.NET Framework will still be around for a decade but is effectively retired and .NET Core 3.0 will fill in any remaining gaps for Windows apps that still need the full framework today.
[+] [-] mrblah|7 years ago|reply
[+] [-] sremani|7 years ago|reply
[+] [-] mandeepj|7 years ago|reply
[+] [-] dep_b|7 years ago|reply
[+] [-] martinald|7 years ago|reply
I tried .NET core a lot pre-1.0 and it seemed really fragile (especially on Mac and Linux, which was my main excitement around it).
As I was a bit nervous about that, I started a new project in 'classic' .NET w/ MVC5. It however seems a lot of projects are migrating rapidly to .NET Core and leaving support for legacy projects recently.
It does seem to be a giant pain to migrate a legacy asp.net app to asp.net core (very manual). Anyone have any tools/advice on this process?
[+] [-] markmark|7 years ago|reply
In 2.0 they had a bit of a rethink about how stripped down Core was going to be and added a heap of stuff in, plus a lot more (most?) big open source libs have been ported. So porting legacy apps is much easier.
However I don't see any point porting a legacy app unless there is something in core you want. Perhaps you'd like to move your app over to running on Linux servers? At my previous company we ported parts of our product so that we could sell cross-platform support without needing our users to install mono.
[+] [-] swalsh|7 years ago|reply
[+] [-] euroclydon|7 years ago|reply
https://docs.microsoft.com/en-us/dotnet/core/tools/?tabs=net...
[+] [-] sebazzz|7 years ago|reply
However, once you have Web Forms in your project there is no way forward but to rewrite the Web Forms pages.
[+] [-] DenisM|7 years ago|reply
I’ve decided to wait it out.
[+] [-] daxfohl|7 years ago|reply
[+] [-] icey|7 years ago|reply
[+] [-] davidgl|7 years ago|reply
[+] [-] Analemma_|7 years ago|reply
a) was addressed by Roslyn, which is apparently much more manageable, and now that .NET is supposed to run everywhere, it has to have competitive performance. Hence the big gains.
[+] [-] neilsimp1|7 years ago|reply
[+] [-] kevindqc|7 years ago|reply
https://github.com/dotnet/coreclr/blob/48cb3fa29a63219a9669a...
[+] [-] benaadams|7 years ago|reply
Then it uses SpanHelpers.SequenceEqual for byte which is vectorized
https://github.com/dotnet/coreclr/blob/04d9b557ef8b7c60a1194...
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] wolf550e|7 years ago|reply
[+] [-] Kirth|7 years ago|reply
[+] [-] pestkranker|7 years ago|reply
[+] [-] mjsabby|7 years ago|reply
[+] [-] yawgmoth|7 years ago|reply
While it's not Bing, this is the canonical example I have seen in response to a lot of "What is at least a very good way to do x in .NET Core?"
[+] [-] paulborza|7 years ago|reply
[+] [-] dasanman|7 years ago|reply
[+] [-] cbHXBY1D|7 years ago|reply
It gets about 21% of the search market.
[+] [-] kuwze|7 years ago|reply
[0]: https://dzone.com/articles/how-raygun-increased-throughput-b...
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] funwie|7 years ago|reply
Mono is open source port of .Net Framework to non-windows platforms (linux, mac os)
.Net Core is cross platform (like Java but without GUI features for now)
.Net Standard for libraries shared by all 3 above.
[+] [-] tracker1|7 years ago|reply
Personally, my first past at most things these days would be with Node.js simply because of productivity, but it's nice to see more options for performance growth as needed.
[+] [-] markbnj|7 years ago|reply
[+] [-] polskibus|7 years ago|reply
[+] [-] wpdev_63|7 years ago|reply
[+] [-] yread|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] h4b4n3r0|7 years ago|reply
[+] [-] mjsabby|7 years ago|reply
[+] [-] benaadams|7 years ago|reply
7+ million requests per second on linux for a single server (maxing out a 10GBps network) isn't to shabby ;)
Also they run continuous benchmarks for all platforms in a wider range of tests https://github.com/aspnet/Benchmarks
With the results being public at https://aka.ms/aspnet/benchmarks
[+] [-] jorgec|7 years ago|reply
[deleted]
[+] [-] lcfcjs|7 years ago|reply
[deleted]