.NET on Artur Rios Lab

How I Develop APIs

Wed, 21 Oct 2026 19:30:00 +0000

Every backend I build is an ASP.NET Core API, and they all look alike on purpose. When the structure is the same everywhere, I never have to remember where a thing lives, a new feature is a list of files to add rather than a design decision, and a test that fails points at one small piece of code.

This page describes that shape, using Heimdall as the example throughout. Heimdall is my identity management API: people, applications, logins, two-factor authentication and permissions, for several client systems at once, each in its own scope. It is the largest API I have, so every pattern here has been tested against a real use case rather than a toy one. All code on this page is taken from it, trimmed only where noted.

The .NET Libraries I Reach For

Wed, 21 Oct 2026 13:20:00 +0000

Every new .NET project starts with the same handful of decisions. How will I test it? Where does fake data come from? How do I validate input, survive a flaky dependency, export a spreadsheet, run something every night? The base class library answers some of these. For the rest, I have settled on a short list of NuGet packages that I add almost without thinking.

This page is that list, with the reasoning written down. For each library I explain what it is for, why I use it, show a small example and say when I would pick something else. A recommendation is only as good as what it leaves out, so I also flag what I would want to know before adding a dependency: licence, maintenance, breaking changes, and in two cases events that every user of the library should know about.

Test Coverage in .NET: What It Measures and How to Collect It

Wed, 21 Oct 2026 13:10:00 +0000

A pull request comes back with a comment: “coverage dropped from 84% to 81%”. What does the number mean? Which 3% went missing, and does it matter? Coverage is one of the few test metrics that every .NET tool can produce for free, and one of the easiest to misread. It is very good at answering which code did no test run? and close to useless at answering are the tests any good?

EF Core or Dapper? Two Ways to Talk to a Database from .NET

Wed, 21 Oct 2026 13:00:00 +0000

Almost every .NET application that stores data ends up choosing how its C# code will talk to a relational database. Two names come up more than any other. Entity Framework Core is Microsoft’s object-relational mapper: you describe your classes, and it writes the SQL, tracks what you change and evolves the schema. Dapper is a small library from Stack Overflow: you write the SQL, and it turns the rows that come back into objects.

C# Delegates: Methods as Values

Wed, 21 Oct 2026 12:50:00 +0000

List<T>.Sort doesn’t know how you want your items ordered, so it asks you: pass it a method that compares two items, and it calls that method whenever it needs to. A button doesn’t know what should happen when it is clicked, so it keeps a list of methods to call. LINQ’s Where doesn’t know which items you want, so it takes a method that answers yes or no for each one. All three need the same thing from the language: a way to treat a method as a value that can be stored in a field, passed as an argument and called later. In C# that value is a delegate.

IEnumerable, ICollection, IList and IQueryable: What Each Collection Interface Promises

Wed, 21 Oct 2026 12:40:00 +0000

Open almost any C# codebase and you will find method signatures that take an IEnumerable<T>, entities with ICollection<T> navigation properties, repositories returning IQueryable<T>, and the occasional IList<T> or IReadOnlyList<T>. They are easy to treat as interchangeable names for “a bunch of items”, and the code usually compiles whichever one you pick. Yet each interface makes a different promise, and choosing the wrong one causes real bugs: a query that runs three times, a database table loaded into memory to be filtered in C#, an exception thrown far from the line that caused it, or a “read-only” list that changes under your feet.

How C# Runs: From Source to IL to Machine Code

Wed, 21 Oct 2026 12:30:00 +0000

A C# program is not compiled straight to machine code, and it is not interpreted either. It is compiled twice. When you build, the C# compiler turns source code into an intermediate language and a description of every type, packed into an assembly, a .dll file. When you run, the .NET runtime turns that intermediate language into machine code for the CPU it is running on, usually one method at a time and often more than once as it learns which code is hot.