Roundup #31: .NET OSS, Async Startup, Loki Serilog, Monitoring, Collectible Assemblies, Alba 3.0

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

Starting the .NET Open Source Revolution

Today building open source software at Microsoft is normal — but when I started at Microsoft in 2007, it sure wasn’t. It took a few years to figure out the right thing to do and to get the big ship that is Microsoft turned into the wind of open source. But we’re there now and I look back on those early challenges with a smile. This is my story of the first successful open source project at Microsoft and how it paved the way to where we are today.


Running async tasks on app startup in ASP.NET Core (Part 1)

Sometimes you need to perform one-off initialisation logic before your app starts up properly. For example, you might want to validate your configuration is correct, populate a cache, or run database migrations. In this post, I look at the options available and show some simple methods and extension points that I think solve the problem well.


Serilog Sink for Loki

This is a Serilog Sink for Grafana’s new Loki Log Aggregator.

What is Loki?

Loki is a horizontally-scalable, highly-available, multi-tenant log aggregation system inspired by Prometheus. It is designed to be very cost effective and easy to operate, as it does not index the contents of the logs, but rather a set of labels for each log stream.


Monitoring GC and memory allocations with .NET Core 2.2 and Application Insights

It all started when we were migrating some of our service from .NET Framework to .NET Core. We have been using Application Insights, using it’s performance counter collection feature to monitor performance counters on our Windows server that run our applications. We soon discovered when we moved over to .NET Core that we’d have to do things differently, since performance counters aren’t supported in Application Insights for .NET Core.


Collectible assemblies in .NET Core 3.0

Since the beginning of .NET Core, the one feature that I have been most anxiously waiting for, has been support for collectible assemblies. It took a while (a while!), but finally, in .NET Core 3.0 (at the time of writing 3.0.0-preview-27122-01 from 2018-12-04), it’s here.

It’s going to be a killer functionality, that will support some excellent use cases in .NET Core – especially around application plugins, extensibility and dynamic assembly generation.


Alba 3.0 – TestServer on steroids and HTTP contract testing for .NET

Alba is a library you can use in combination with xUnit/NUnit to much more easily author integration tests against ASP.Net Core applications by running HTTP requests in process.


Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #30: ProxyKit, BeeHive, Nullable Ref Types, Close Loops & Opening Minds

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


A toolkit to create HTTP proxies hosted in ASP.NET Core as middleware. This allows focused code-first proxies that can be embedded in existing ASP.NET Core applications or deployed as a standalone server. Deployable anywhere ASP.NET Core is deployable such as Windows, Linux, Containers, and Serverless (with caveats).



Zero Friction mini-Framework for cloud Actors – currently for Windows Azure only. Implementation is very simple – if you need a complex implementation of the Actor Model, you are probably doing it wrong. It supports .NET Framework 4.5.2+ and .NET Standard 2.0+.


C# 8 Nullable Reference Types

C# 8.0 will introduce a new groundbreaking feature called Nullable reference types, this feature will change the way we currently develop our software in C# by making, you guessed it, reference types nullable.


Close Loops & Opening Minds: How to Take Control of Systems, Big & Small

Whether it’s distributing configurations and customer settings, launching instances, or responding to surges in load, having a great control plane is key to the success of any system or service. Come hear about the techniques we use to build stable and scalable control planes at Amazon. We dive deep into the designs that power the most reliable systems at AWS. We share hard-earned operational lessons and explain academic control theory in easy-to-apply patterns and principles that are immediately useful in your own designs.


Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Practical ASP.NET Core SignalR: Server Hubs

Practical ASP.NET Core SignalR

In this section, I’m going to extend my existing ASP.NET Core application to explore more of what SignalR Server Hubs have to offer.

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.

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

  1. Course Overview
  2. ASP.NET Core SignalR Overview
  3. Basics

SignalR Server Hubs

A SignalR Server Hub is a primary point at which all communication between client and server occur.  You define methods in a hub that can be called by the client. And in the client code, we can define methods that our hub can call.

We can define methods on our hub that can communicate directly with the specific client (caller) who is making the call to our hub. I’m going to add a new method to our existing MessageHub called SendMessageToCaller


We can also send data to specific clients. To do so, we simply need to know the ConnectionId of the client we want to send data to.

I’ll add a new method called SendMessageToUser which will accept a connectionId as the first parameter which we will use.

In order for our clients to know about each other, I’m going to override two methods on our Hub. OnConnectedAsync and OnDisconnectedAsync. I’ll use these methods to let all connected clients know when a new client as connected or disconnected. This way the clients/browser can keep track of the ConnectionID’s available, in order to send to specific clients.


Lastly, we can also define Groups of connections. This giving us the ability to send data to specific groups. This is often useful for multi-tenant applications.

I’ll create two new methods, one method JoinGroup which will be used for our clients to join a specific group. SendMessageToGroup will be used to send data to the specific clients that have already called JoinGroup.


First, I’ll update my Razor Page to contain a new select list to specify who we want to send the message to, All, Myself or PrivateGroup. I’ll also add a button that we will wire-up to call our JoinGroup on our Hub.

Now we will wire up our new UI by adding in SignalR client handlers for UserConnected, UserDisconnected events. I’ll also add UI for the Join button click as well as using the select list to determine which methodto invoke on our Hub.

Get The Course!

You’ve got several options:

  1. Check out my Practical ASP.NET Core SignalR playlist on my CodeOpinion YouTube channel.
  2. Access the full course now by enrolling for free on Teachable.
  3. Follow along with the blog post series here on
    1. Course Overview
    2. ASP.NET Core SignalR Overview
    3. Basics
    4. Server Hubs
    5. HubContext
    6. Authorization
    7. Scaling with Redis
    8. Scaling with Azure SignalR Service

Source Code

All of the source code for this blog post and this course is available the Practical.AspNetCore.SignalR repo on GitHub.