Tag: CSharp
All the articles with the tag "CSharp".
-
Using operator overloads for concatenating file system paths in 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): Whoa! This almost looks like path separators! And the great thing is that this also returns a platform-specific path.
-
Building a scheduled task in ASP.NET Core/Standard 2.0
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. At JetBrains, various teams make use of a Slack bot, which we write in Kotlin. This bot performs various tasks, ranging from saying “Hi!” to managing our stand-ups to keeping track of which developer manages which part of our IDE’s. While working on the bot code, I found this little piece of code:
-
Making string validation faster by not using a regular expression. A story.
-
Extending .NET CLI with custom tools - dotnet init initializes your NuGet package
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. What I personally like about the new .csproj format, is how easy it is to create NuGet packages with it. Just add a few MSBuild properties, run msbuild pack or dotnet build and be done with it. But which properties are available? A whole list, it seems. Let me introduce you to a tool to make this easier, and how it was built.
-
Using dotPeek to figure out why IIS crashed
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. Nothing better than a good cup of coffee in the morning! Opening up the issue tracker, “the folks from IT” logged an issue about an application server crashing over night. They automatically captured a crash dump of the IIS worker process and attached it to the issue - this should help in diagnosing the root cause of that crash. One more coffee refill, and then let’s dive in!
-
Application Insights telemetry processors
-
Exploring .NET managed heap with ClrMD
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. So what is ClrMD? ClrMD is the short name for the Microsoft.Diagnostics.Runtime package which lets us inspect a crash dump or attach to a live process and perform all sorts of queries against the runtime. For example walking the heap (which we’ll do later), inspecting the finalizer queue, and more. In this series:
-
Exploring memory allocation and strings
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:
-
Making .NET code less allocatey - Allocations and the Garbage Collector
-
Building NuGet (.NET Core) using Atlassian Bitbucket Pipelines
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: