What makes coding more "fun" is the .NET framework. It had its headaches, but its a really nice and polished framework for getting things up and running. Especially with web building. .NET 4+, C#, and Core are Microsoft's message to the development world that they hear us.

Here's hoping they continue with this trend.

That and C# is an ISO standard which is pretty cool.

1. Facing a code task.

2. Asking myself, should I reinvent the wheel or should I look for a library?

3. Google for libraries solving the task, open at least 5 npm/github tabs.

4. For every tab, I should make sure the library is not too big for my needs/popular/still being maintained/not too many open issues. -Closing the tabs that didn't pass this step.

5. Taking a look at documentation/examples to determine if it can solve my problem. -Closing the tabs that didn't pass this step.

6. Testing the library and see if I can make it work.

7. Implement it in my project.

It's a really different environment, and it has its advantages, it's just that Microsoft has spoiled me a little with their out of the box implementations.

Microsoft publish older versions of C# through ECMA, but that documentation is always behind the implementations (which are all now owned by Microsoft). The latest ECMA document is for version 5.0 of C#.

I'm also fairly exited for Blazor so I can write fullstack C#.

I'm curious, compared to what?

actually when I looked at .net core 1.0 I basically already tought it is abadonware, because of the new build system, because i wasn't a huge fan of c# and lot's of stuff just didn't worked, but since we needed to migrate our old WebForms application I somehow tought that before rewriting everything, it might be a good idea to look into it and it somehow clicked. c# is really moving fast and the recent additions even makes myself as a scala programmer feel more at home.

[0]: https://github.com/aspnet/JavaScriptServices [1]: https://github.com/aspnet/Announcements/issues/289

On the other hand, the standard library that .NET provides is superior.

From my experience, it's possible to deploy a .NET site with just a hand-full of 3rd party dependencies (if any).

https://dotnetthoughts.net/using-node-services-in-aspnet-cor...

That what made my decision to use dotnet core for web app

There's certainly something to be said for an easy way to get running quickly, when you can't be bothered with an SPA.

...but it doesn't scale. :)

(^ the comparison is more apt than you might imagine; razor pages are the 'one file per logical page' model for asp .net core, and very very reminiscent of webforms, and all the legacy that carries).

I'm just saying: Microsoft have done some excellent work with .net core and kestrel but that doesn't mean every idea they have is a good one)

btw. razor pages doesn't mean that you need to write spaghetti code. I've seen tons of MVC code where the view layer got way too much code.

most of the time it will help if people actually only put the bare minimum of code into the view layer. (only if/for/etc where absolute necessary)

If I was under the impression the ASP.NET team was on the ball and agreed with the decision they were making, I'd be more prepared to run with it... but I'm not.

For example, there's an open github issue discussing the concerns people have raised about the ASP.NET team suggesting that razor pages are better than MVC.

Read it yourself and you'll be extremely familiar with the various opinions on the matter:

https://github.com/aspnet/Docs/issues/6146

This, is again, as I said before, an example of not everything that (specifically the ASP.NET team) does, being a good idea.

as said my background was basically 5 years or more working in mvc and even partially working on the framework itself. and I would say that Razor Pages is a good starting point for any application.

currently I think both, Razor Pages AND MVC is important, but it's so easy to use both, so there is no problem. If something grows to much you can easily split it into the old traditional MVC paradigma, but actually most of the time I migrate directly to a web api instead of dotnet core mvc. (at the moment I have 2 mvc controllers, which are basically the same as web api 2 endpoints (no view/no model))

also razor pages is kind of MVVM which is common more (i mean in the javascript world more stuff is mvvm than mvc, not sure why java/c# can't follow that aswell?!) and more for UI related frameworks (which razor pages of course is) but most people didn't realized that on this github issue..

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.

It is still awesome that the community can comment, and Microsoft does take community changes regularly for .Net Core, VS Code, etc.

.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 (Windows only), .Net Core and Xamarin are all implementations of .Net Standard.

To add even more confusion, ASP.Net Core can run either on .Net Core or .Net Framework.

.Net Standard is an "Interface" - No implementation behind the scenes just a list of apis.

.Net Framework, .Net Core, Xamarin are all "classes" or implementations of .Net Standard.

ASP.NET Core only relies on .NET standard which is implemented by both .Net Framework and .Net Core. Which means it can run on both.

ASP.NET (Framework) does not rely on .Net Standard but directly links to the implementation of .Net Framework. Which means those libraries can't run anywhere and are instead limited to only .NET Framework.

I'm no Jon Skeet, or tech guru. So please take this explanation with a grain of salt and if I'm wrong correct me as needed. This is just how I've wrapped my head around it.

https://gist.github.com/davidfowl/8939f305567e1755412d6dc0b8...

System.web itself is over 2 mb and you don't need everything from it, all the time. Cross platform was another feature which was hard to do w\o starting over

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.

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

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).

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 :)

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

> 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.

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.

.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.

Then .NET Framework, .NET Core, Mono, Unity, etc runtimes then implement that contract so a library built against .Net Standard will work on any of the runtimes.

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?

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.

Yeah, this.

For example, originally they weren't going to include SqlDBAdapter or DataTables or any related classes. They really just thought everybody was going to be okay with using Entity Framework for everything and not having a generic, non-ORM database interface.

Most of my coding involves either extremely simple tables or where I want to manipulate tables for third-party applications that have over a thousand tables where I don't have access to the source code. Most of it is ETL or ETL-like. It's also usually in PowerShell or Python, but some of it is in C#. Making an EF would take ages for some of these applications, especially when the schema isn't always relationally sound (but it's third party so I can't change it). It still just blows my mind they they thought it'd be okay to make everybody box and unbox their database into classed objects instead of just letting you manipulate it as a DataRow. As far as I know, they still consider DataTable and the like to be "legacy".

They've fixed all of that stuff.

https://docs.microsoft.com/en-us/dotnet/core/tools/?tabs=net...

Do you think they will drop VS and adopt VS Code as the recommended solution? Since it's locked to Windows, bloated and there's no 64 bits version

But more importantly VS and VS Code are two different approaches- IDE vs TextEditor. The vast majority people would say C#, as a compiled language, is best in an IDE. Either way, I'm pretty confident in predicting that there is no way Visual Studio gets "dropped."

They have moved more and more features to run into separate child processes to prevent the memory use requirements for the main VS process. VS 2017 uses a lot more memory than 2013 (the previous one I used). My 8GB machine gets slowdowns every now and due to SQL Server getting swapped out.

However, once you have Web Forms in your project there is no way forward but to rewrite the Web Forms pages.

The startup and identity/authentication is a bit different though.

I’ve decided to wait it out.

If it wasn't for that, I wouldn't be worried at all...

Maybe you can convince them to stay the course by citing their own tagline? It says legacy right there.

We provide a universal authentication & authorization platform for web, mobile, and legacy applications.

Who needs "features" anyway?

Near future: Windows Server 2019 + http.sys + ASP.NET Core

Medium future: Windows Server 2019 + Kestrel + ASP.NET Core

https://docs.microsoft.com/en-us/aspnet/core/fundamentals/se...

https://docs.microsoft.com/en-us/aspnet/core/fundamentals/se...

You can also build your reverse proxy using Kestrel.

Though IIS is more battle tested so they may be using that as front line server for such a high profile service as Bing

It looks like they're planning to move off Windows - or, at least giving themselves the option to.

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.

Almost all of the 'compiler' optimisations are done by the JIT at run-time when it converts the IL code into machine/assembly code

https://news.ycombinator.com/item?id=16225696

>... the final precipitous drop (on June 2) is the deployment of .NET Core 2.1! That is a 34% improvement ...

If so, that graph seems to be deliberately misleading.

If latency is 1 minute and they've shaved 22 seconds off (37%), neat. But it's still bad.

If anything, the deliberate omission of scale on that Y axis is really disturbing.

https://github.com/dotnet/coreclr/blob/48cb3fa29a63219a9669a...

Then it uses SpanHelpers.SequenceEqual for byte which is vectorized

https://github.com/dotnet/coreclr/blob/04d9b557ef8b7c60a1194...

To be clear, char is not cast to byte (which would truncate). A char ref (ie a char pointer) is cast to a byte ref (ie a byte pointer).

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?"

It gets about 21% of the search market.

I do not know if they have done it on purpose, but kudos to the Bing team either way.

[0]: https://dzone.com/articles/how-raygun-increased-throughput-b...

The title is "How Raygun Increased Throughput by 2,000% With .NET Core (Over Node.js)". From the article:

> In terms of EC2, we utilized c3.large nodes for both the Node.js deployment and then for the .NET Core deployment. Both sit as backends behind an NGINX instance and are managed using scaling groups in EC2 sitting behind a standard AWS load balancer (ELB).

They're comparing their Node.js vs C# versions behind ELB and NGINX. It's barely touching the networking part of the stack directly. They gains are almost definitely all from a stronger compiler story and a concurrency story.

They say themselves:

> Node is a productive environment and has a huge ecosystem around it, but frankly, it hasn’t been designed for performance.

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.

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.

Then you come down to issues like Linux networking vs. Windows networking, Disk I/O differences which are interesting but from a .NET perspective less so in my opinion.

Exciting to hear. .NET is truly a diamond in the rough on the Linux side, its only major problem seems to be catch-22 in the sense that few people use it there, so the ecosystem is slow to come in.

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

I heard Bing good for porn, it's probably the one strong side, LOL.