Practical ASP.NET Core SignalR Overview

Practical ASP.NET Core SignalRASP.NET Core SignalR is an excellent way to add real-time functionality to your web applications.  You may be wondering, what exactly is real-time web functionality and what problem does that solve?

Here’s an overview of what problems SignalR solves, and how it does it using various technologies.

This blog post is apart of a course that is a complete step-by-setup guide on how to build real-time web applications using ASP.NET Core SignalR. By the end of this course, you’ll be able to build real-world, scalable, production applications using the tools and techniques provided in this course.

What you’ll learn:

  • Creating ASP.NET Core SignalR Hubs
  • Connecting to Hubs using JavaScript Clients
  • Scaling your application using Redis and Azure

If you haven’t already, check out the prior sections of this course.

  1. Course Overview

 

ASP.NET CoreSignalR Overview

ASP.NET Core SignalR: Problem Space

ASP.NET Core SignalR: Push

ASP.NET Core SignalR: Summary

 

Get The Course!

If you want all the content right now, you can access the full course now by enrolling for free on Teachable.  Otherwise stay tuned to this blog and my YouTube Channel for all the content in the coming weeks.

 

Roundup #24: JSON, .NET Core 3, Framework Reference, Orleans Dashboard

Here are the things that caught my eye this week.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

 

The future of JSON in .NET Core 3.0

JSON has become an essential part of virtually all modern .NET applications and in many cases even surpassed the usage of XML. However, .NET hasn’t had a (great) built-in way to deal with JSON. Instead we’ve relied on Json.NET which continues to serve the .NET ecosystem well.

Moving forward, we plan on making some changes to our JSON support.

Link: https://github.com/dotnet/announcements/issues/90

 

A first look at changes coming in ASP.NET Core 3.0

While we continue to work on finalizing the next minor version of ASP.NET Core, we’re also working on major updates to our next release that will include some changes in how projects are composed with frameworks, tighter .NET Core integration, and 3rd party open source integration, all with the goal of making it easier and faster for you to develop. For broader context around .NET Core 3.0, we encourage you to check out our previous announcements around the addition of WinForms and WPF support to .NET Core 3.0 on Windows. We’ll publish more details about new features coming in ASP.NET Core 3.0 in the near future.

The big takeaway for me was that ASP.NET Core 3.0 will only run on .NET Core 3.  This means no more .NET Standard support.  In other words, no longer supporting .NET Framework.

Link: https://blogs.msdn.microsoft.com/webdev/2018/10/29/a-first-look-at-changes-coming-in-asp-net-core-3-0/

 

ASP.NET Core 3.0 will only run on .NET Core

As announced on the .NET Blog earlier this month, .NET Framework will get fewer of the newer platform and language features that come to .NET Core moving forward, due to the in-place update nature of .NET Framework and the desire to limit changes there that might break existing applications. To ensure ASP.NET Core can fully leverage the improvements coming to .NET Core moving forward, ASP.NET Core will only run on .NET Core starting from 3.0. Moving forward, you can simply think of ASP.NET Core as being part of .NET Core.

Here’s a link to the discussions thread since the previous link contains the announcement.

Link: https://github.com/aspnet/AspNetCore/issues/3753

 

Replace PackageReference to Microsoft.AspNetCore.App with FrameworkReference

Most NuGet packages provide both compilation and runtime assets. Microsoft.NETCore.App and Microsoft.AspNetCore.App effectively only provide the first – compilation references. Users must install other runtime assets to make .NET Core apps work but this is not obvious or intuitive, and not always possible: for example, Azure Web Apps, AWS, Google Cloud, etc. This violates a reasonable expectation of using a NuGet package, and has been a continual source of confusion for users.

Link: https://github.com/aspnet/AspNetCore/issues/3612

 

.NET Standard v2.0 vs v2.1

Neat object model diagram showing the differences between .NET Standard 2.0 and 2.1.

Link: https://sharpgis.net/omds/NetStd21_WhatsNew.html

 

Microsoft Orleans Reporting Dashboard

Orleans is an easy to use actor framework, but how can you monitor your deployment? Luckily, there’s something simple to use — Orleans Dashboard!

Link: https://medium.com/@kritner/microsoft-orleans-reporting-dashboard-16465d255199

 

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Upgrading Nancy to Version 2

Upgrading NancyAlthough there isn’t an “official” of Nancy v2 release yet, there’ is 2.0.0-clinteastwood that’s been in NuGet since Dec 12th, 2106 and as of this post has almost 200k downloads.  The primary reason for upgrading Nancy to v2 is because of its support for NETStandard 1.6 which means you can move to .NET Core.

In this demo, I’m going to be using ASP.NET Core with Owin and Nancy 2.0.0-clinteastwood to add back in the existing routing functionality that is a breaking change in v2.

Breaking Changes

There’s an upgrade notes page on the Nancy Wiki, which lists some of the breaking changes.  Although there aren’t many, and I suspect most of the work for the 2.0 release was for targeting NETStandard.

The most glaring breaking change is with routing.

Routing

Routing syntax has changed to Get("/", args => "Hello World");, these can be made async by adding the async/await keywords. For more info see the PR where it all changed https://github.com/NancyFx/Nancy/pull/2441

This is really significant.   In Nancy V1, you specified routes using the following:

If you have a large web app with many routes and modules, although a trivial change, this could take some significant time.

NancyV1Module

I decided to try to create a new module that would add back the existing routing behavior by calling the new underlying methods in the NancyModule.  This would allow me to simply change all my existing modules to extend this new class rather than the new Module in Nancy v2.

Usage

This then adds back in all the existing routing.  Just simply extend NancyV1Module instead of NancyModule.

Upgrading Nancy

I’ve created a console application with the source available on GitHub.

Have you ran into any significant issues when upgrading Nancy to v2?  Please let me know on Twitter or in the comments.

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.