Tag: CSharp

The past few days, I’ve been working on some cross-platform C# code. In this code, I needed to build a path to a file, by concatenating folder names. As you may know the path separator on Windows and Linux operating systems are different: one has a backward slash (\), the other has a forward slash (/). Luckily for me, the .NET framework(s) contain a utility function for this: Path.Combine handles this for me! Here’s an example: This will generate a platform-specific path: Great! However, I found something else in the codebase I was working on (ReSharper):

In this post, we’ll look at writing a simple system for scheduling tasks in ASP.NET Core 2.0. That’s quite a big claim, so I want to add a disclaimer: this system is mainly meant to populate data in our application’s cache in the background, although it can probably be used for other things as well. It builds on the ASP.NET Core 2.0 IHostedService interface. Before we dive in, I want to give some of the background about why I thought of writing this.

A while back, we were performance profiling an application and noticed a big performance bottleneck while mapping objects using AutoMapper. Mapping is of course somewhat expensive, but the numbers we were seeing were way higher than expected: mapping was ridiculously slow! And “just mapping” was not a good explanation for these numbers. Trusting the work of Jimmy and trusting AutoMapper, we expected something else was probably causing this. And it was: a regular expression match was to blame!

A few weeks back, .NET Core 1.1 was released (and a boatload of related tools such as Visual Studio 2017. For .NET Core projects, a big breaking change was introduced: the project format is no longer project.json but good old .csproj. That’s a little bit of a lie: the .csproj is actually an entirely new, simplified format that combines the best of the old .csproj and project.json and works with .NET Standard and .NET Core.

Here’s a story on how I once used dotPeek to provide debugger symbols and (decompiled) source code for a crashed application for which we had nothing but the application assemblies available. Namespaces have been altered to protect the innocent.

Two weeks ago I had a wonderful experience speaking at a small conference in Finland. The talk was titled What is going on - Application diagnostics on Azure (slides) and focused on the importance of semantic logging and how Azure Application Insights (AppInsights) can help make sense of that data and correlate it with other telemetry coming from the application server. What I did not cover in that talk was AppInsights telemetry processors - essentially a pipeline through which your server-side AppInsights data passes before it is sent off to the giant data store that is the AppInsights service.

Since my posts on making code allocate less memory and memory allocation for strings were quite well received, I decided to add another post to the series: Exploring .NET managed heap with ClrMD. In this post, we’ll explore what is inside .NET’s managed heap (you know, the thing where we alocate our objects), how it’s structured and how we can do some cool tricks with it. We’ll even replicate dotMemory’s dominators/path to root feature.

A while back, I wrote about making code allocate less memory (go read it now if you haven’t). In that post, we saw how the Garbage Collector works and how it decides to keep objects around in memory or reclaim them. There’s one specific type we never touched on in that post: strings. Why would we? They look like value types, so they aren’t subject to Garbage Collection, right? Well… Wrong. Strings are objects like any other object and follow the same rules. In this post, we will look at how they behave in terms of memory allocation. Let’s see what that means. In this series:

The .NET Garbage Collector (GC) is quite cool. In combination with the runtime’s virtual memory, it helps providing our applications with virtually unlimited memory, by reclaiming memory that is no longer in use and making it available to our code again. By doing so, it also takes away the burden of having to allocate and free memory explicitly. But sometimes, it still matters to understand when and where memory is allocated. The reason for that is simple: if we can use efficient coding to help our GC spend less CPU time allocating and freeing memory we can make our applications faster and less “allocatey”.

A while back, I signed up for the beta of Bitbucket Pipelines, a new continuous integration service from Atlassian, built into Bitbucket. The build system promises easy configuration using YAML files to describe the build steps. It runs builds in a Docker image, so that means we can also use it for building and packaging .NET Core libraries. Let’s see how. I created a simple .NET Core library which contains a useless Hello.cs class, and a project.json that holds project metadata. The class itself is not very interesting, the project.json file is: