One feature of .net core 2.2 that didn’t catch my mind immediately is the startup hooks. Put simply, this is a way to register globally a method in an assembly that will be executed whenever a .net core application is started. This unlocks a whole range of scenarios, from injecting a profiler to tweaking a static context in a given environment.
This post follows on somewhat from my recent posts on running async startup tasks in ASP.NET Core. Rather than discuss a general approach to running startup tasks, this post discusses an example of a startup task that was suggested by Ruben Bartelink. It describes an interesting way to try to reduce the latencies seen by apps when they’ve just started, by pre-building all the singletons registered with the DI container.
Pipelines was born from the work the .NET Core team was doing to make it easier to do high performance IO in .NET.
In this episode, Pavel Krymets (@pakrym) and David Fowler (@davidfowl) come on the show to give us an overview of how the Pipelines programming model works, as well as give show us a few demos on how to use the API.
If you’re an active Rider 2018.3 user or just follow our blog, you probably know that Rider just got an integrated performance profiler based on JetBrains dotTrace. Though we’ve already reviewed the profiler features on the EAP stage, the release version brings some important changes, especially concerning profiling session configuration. Read this post to learn more about the changes.
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.
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.
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.
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.
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.