DEV Community: Naze Code

How big is Hello World in C#? From 76 MB down to 0.73 MB

Naze Code — Sun, 11 Oct 2026 13:26:03 +0000

How big is the smallest C# program? It depends almost entirely on how you publish it. Same one line of code, five different dotnet publish commands, and the result ranges from a 76 MB folder of 191 files to a single 0.73 MB executable.

Machine: .NET SDK 10.0.302, Windows 11 x64. Sizes exclude .pdb files. Start time is the median of 21 runs of "start the process, print, exit", after a warm-up run.

The program under test:

Console.WriteLine("Hello, World!");

The five ways it was published:

("1 default (needs .NET)",  ""),
("2 self-contained",        "--self-contained -r win-x64"),
("3 trimmed single file",   "--self-contained -r win-x64 -p:PublishSingleFile=true -p:PublishTrimmed=true"),
("4 Native AOT",            "-r win-x64 -p:PublishAot=true"),
("5 Native AOT, tiny",      "-r win-x64 -p:PublishAot=true -p:OptimizationPreference=Size " +
                            "-p:InvariantGlobalization=true -p:UseSystemResourceKeys=true -p:StackTraceSupport=false"),

(Each line is appended to dotnet publish Hello.csproj -c Release.) The results:

1 default (needs .NET)
  size:       0.16 MB, 4 files
  start+exit: 39 ms
2 self-contained
  size:       76.63 MB, 191 files
  start+exit: 40 ms
3 trimmed single file
  size:       12.30 MB, 1 files
  start+exit: 132 ms
4 Native AOT
  size:       1.06 MB, 1 files
  start+exit: 7 ms
5 Native AOT, tiny
  size:       0.73 MB, 1 files
  start+exit: 7 ms

Sizes were identical on every run. Start times varied by a few milliseconds (for example 39–41 ms for the default, 132–141 ms for the trimmed single file), so treat them as "on my machine".

1. Default: 0.16 MB, but it isn't the whole story

The default publish is tiny because it contains only your code: Hello.dll, a small Hello.exe launcher and two config files. Everything else, the runtime and the base libraries, has to already be installed on the machine. That's a framework-dependent app. Great when you control the servers; a problem when you hand an .exe to someone without .NET.

2. Self-contained: 76.63 MB, 191 files

--self-contained ships the runtime with the app, so it runs on a machine with no .NET installed. The price: the whole runtime and base class library come along, 191 files for one line of code. Start time is about the same as the default, since it's the same runtime doing the same work.

3. Trimmed single file: 12.30 MB, one file

PublishTrimmed removes the parts of the libraries your code never uses, and PublishSingleFile bundles everything into one .exe. Down to 12 MB and one file.

Two catches:

Trimming can break code that uses reflection. The trimmer can't always see what will be loaded by name at runtime, so it may remove it. It warns you at publish time; take those warnings seriously.
In this test, this build started the slowest: about 130–140 ms, more than three times the default. I didn't dig into why, so I'll just report it: measure before choosing it for something that starts often, like a CLI tool.

4. Native AOT: 1.06 MB, 7 ms

PublishAot compiles everything ahead of time into native machine code. No separate runtime to load and no JIT compiling methods at startup. The result is a single 1 MB executable that started in 7 ms, about five times faster than the default.

The trade-off is that the program can't generate new code at runtime. Anything that relies on that (some reflection-heavy libraries, dynamic proxies, runtime code generation) needs to be AOT-compatible. On Windows, it also needs the Visual Studio C++ build tools installed to link.

5. Native AOT tuned for size: 0.73 MB

Four more switches, each giving up something a Hello World doesn't need:

OptimizationPreference=Size: tell the compiler to prefer smaller code over faster code.
InvariantGlobalization=true: drop culture-specific data (number and date formats per country). Fine here; not fine for an app that formats dates for users in many countries.
UseSystemResourceKeys=true: exception messages become resource keys instead of full text.
StackTraceSupport=false: less information in stack traces.

Result: 0.73 MB, about a hundred times smaller than the self-contained build, and still starting in 7 ms.

Which one should you use?

Web apps and services on servers you control: the default. Small deploys, and the runtime gets patched separately.
A tool you hand to people who may not have .NET: self-contained, or Native AOT if your dependencies support it.
CLI tools, serverless functions, containers where startup time matters: Native AOT is worth trying first.
The size-tuned switches: only when size really matters and you can live without what they remove.

Try the commands above on your machine and post your numbers in the comments. I'm curious how much start times vary.

I make short, tested videos about C# and what happens when you measure it. More on the Naze Code YouTube channel.

Sources: Microsoft Learn, .NET application publishing overview, Trim self-contained deployments, Native AOT deployment, Optimize AOT deployments. Tested on .NET SDK 10.0.302 (runtime 10.0.10), Windows 11 x64.

Why LINQ is lazy: IEnumerable and yield in C#, explained by running it

Naze Code — Sun, 11 Oct 2026 13:25:17 +0000

LINQ is lazy: Where and Select don't do anything until you loop over the result. Most people learn that as a rule. But it isn't LINQ magic. It comes straight from yield return, and once you see how yield works, LINQ's behavior stops being surprising.

Four small experiments, run for real on .NET 10 (Release build).

1. Nothing runs until someone asks

static IEnumerable<int> Numbers()
{
    for (var i = 1; i <= 3; i++)
    {
        Console.WriteLine($"  producing {i}");
        yield return i;
    }
}

var numbers = Numbers();
Console.WriteLine("Numbers() called");

foreach (var n in numbers)
    Console.WriteLine($"got {n}");

Numbers() called
  producing 1
got 1
  producing 2
got 2
  producing 3
got 3

Two things to notice:

Calling Numbers() ran none of its body. "Numbers() called" printed first.
After that, producing and consuming take turns. The loop asks for one item, the method runs until the next yield return, hands it over, and pauses there until the loop asks again.

That's exactly why a LINQ query runs when it's read, not when it's written: Where, Select and friends are built the same way.

2. What the compiler turns `yield` into

A method can't really "pause" halfway. So the compiler rewrites an iterator method into a hidden class that remembers where it was. Reflection can find it:

var machine = typeof(Demo).GetNestedTypes(BindingFlags.NonPublic)
    .Single(t => t.Name.Contains("Numbers"));

Console.WriteLine(machine.Name);
foreach (var i in machine.GetInterfaces())
    Console.WriteLine($"  implements {i.Name}");
foreach (var f in machine.GetFields(BindingFlags.Instance | BindingFlags.NonPublic))
    Console.WriteLine($"  {f.FieldType.Name,-8} {f.Name}");

<Numbers>d__0
  implements IEnumerable`1
  implements IEnumerable
  implements IEnumerator`1
  implements IDisposable
  implements IEnumerator
  Int32    <>1__state
  Int32    <>2__current
  Int32    <>l__initialThreadId
  Int32    <i>5__2

<>1__state is where it paused: which yield return to continue after.
<>2__current is the value just yielded (what Current returns).
<i>5__2 is your loop variable i, moved into a field so it survives between calls.
<>l__initialThreadId is a small optimization: the first foreach on the thread that created the sequence can reuse this same object as its enumerator instead of allocating a new one.

The class is both the sequence (IEnumerable) and the cursor (IEnumerator). Each MoveNext() call runs your code up to the next yield return. It also implements IDisposable, which matters in the next part.

3. Infinite sequences and early stops

static IEnumerable<int> Naturals()
{
    try
    {
        for (var n = 1; ; n++) { produced++; yield return n; }   // no exit
    }
    finally { Console.WriteLine("  cleanup ran"); }
}

var firstEvens = Naturals().Where(n => n % 2 == 0).Take(3);

Console.WriteLine(string.Join(", ", firstEvens));
Console.WriteLine($"produced: {produced}");

  cleanup ran
2, 4, 6
produced: 6

The loop has no exit, and it still finished, after producing exactly 6 numbers. Each item is pulled through the chain one at a time, and once Take(3) has three, it stops asking.

And the finally still ran: when the consumer stops early, it disposes the enumerator, and disposing a paused iterator runs its pending finally blocks. ("cleanup ran" prints first because string.Join reads the whole sequence, which disposes it, before the result is printed.) That's what makes it safe to yield from inside a using block that holds a file or a connection.

4. The argument check that runs too late

static IEnumerable<string> ReadLines(string path)
{
    if (path is null) throw new ArgumentNullException(nameof(path));
    foreach (var line in File.ReadLines(path))
        yield return line;
}

IEnumerable<string> lines;
try { lines = ReadLines(null!); }
catch (ArgumentNullException) { Console.WriteLine("caught at the call"); return; }

Console.WriteLine("no exception yet...");
Console.WriteLine(lines.Count());

no exception yet...
Unhandled exception. System.ArgumentNullException: Value cannot be null. (Parameter 'path')
   at P4.Bad.ReadLines(String path)+MoveNext() in ...\Parts.cs:line 92
   at System.Linq.Enumerable.Count[TSource](IEnumerable`1 source)

(Path shortened.) The null check is part of the iterator body, so like everything else in it, it doesn't run until the first MoveNext(). The try around the call caught nothing. The exception came out of Count(), which could be in a completely different part of the program, long after the bad call.

Fix: split the method. Validate in a normal method, then return a local iterator function.

static IEnumerable<string> ReadLines(string path)
{
    ArgumentNullException.ThrowIfNull(path);   // runs now
    return Iterate(path);

    static IEnumerable<string> Iterate(string path)
    {
        foreach (var line in File.ReadLines(path))
            yield return line;
    }
}

Same calling code:

caught at the call

Recap

Calling an iterator runs nothing. Each MoveNext() runs to the next yield return.
The compiler turns it into a class with a state field, the current value and your locals.
Consumers that stop early dispose the iterator, so finally and using still run.
Validate arguments in a wrapper method, not inside the iterator.

Did part 4 ever bite you? Tell me in the comments.

I make short, tested videos about C# and what's really going on under the hood. More on the Naze Code YouTube channel.

Sources: Microsoft Learn, yield statement, Iterators, Deferred execution and lazy evaluation. Tested on .NET SDK 10.0.302, Release build.

5 ways null gets past C# nullable reference types

Naze Code — Sun, 11 Oct 2026 13:25:11 +0000

Nullable reference types are one of the best things to happen to C#. Turn them on, fix the warnings, and most null bugs show up while you type.

Most, not all. Nullable analysis is a compile-time check of your code. It doesn't change what happens at runtime, and it can't see data that comes from outside. Here are five ways null still gets through. In this project, with <Nullable>enable</Nullable>, four of them build with zero warnings. Every output is copied from actually running them on .NET 10.

1. The `!` that only silences the compiler

string nickname = null!;          // "trust me, it's not null"

Console.WriteLine($"Hi, {nickname.ToUpper()}!");

Unhandled exception. System.NullReferenceException: Object reference not set to an instance of an object.

The null-forgiving operator ! tells the compiler to stop warning. That's all it does: no check, no exception at the assignment, nothing at runtime. Every ! is a promise the compiler can't verify.

Fix: if it can be null, say so, and handle it.

string? nickname = null;          // honest: it might be null

Console.WriteLine($"Hi, {nickname?.ToUpper() ?? "friend"}!");

Hi, friend!

2. JSON that doesn't read your annotations

public class User
{
    public string Email { get; set; } = "";
    public string Name { get; set; } = "";
}

var json = """{ "email": "ada@x.dev", "name": null }""";

var user = JsonSerializer.Deserialize<User>(json, JsonSerializerOptions.Web)!;
Console.WriteLine(user.Name.Length);

Unhandled exception. System.NullReferenceException: Object reference not set to an instance of an object.

Name is a non-nullable string with a default of "". But the JSON explicitly says null, and by default System.Text.Json sets it, regardless of your annotations. The compiler checked your code; nobody checked the data.

Fix: since .NET 9, you can tell the serializer to enforce the annotations. required also rejects a property that's missing entirely.

public class User
{
    public required string Email { get; set; }
    public required string Name { get; set; }
}

var options = new JsonSerializerOptions(JsonSerializerOptions.Web)
{
    RespectNullableAnnotations = true,
};
var user = JsonSerializer.Deserialize<User>(json, options)!;

Unhandled exception. System.Text.Json.JsonException: The property or field 'name' on type 'T2.Good.User' doesn't allow setting null values. Consider updating its nullability annotation. Path: $.name | LineNumber: 0 | BytePositionInLine: 36.

It still fails, but now it fails at the boundary, with a message that says exactly which field was null, instead of somewhere deep in your code later.

3. Arrays start full of nulls

var names = new string[3];        // string, not string?
names[0] = "Ada";

foreach (var name in names)
    Console.WriteLine(name.Length);

3
Unhandled exception. System.NullReferenceException: Object reference not set to an instance of an object.

new string[3] creates three slots, and every slot starts as null. The type says string, not string?, and the compiler doesn't track individual array elements, so no warning.

Fix: use a collection that only contains what you actually put in it.

var names = new List<string>();   // only holds what you add
names.Add("Ada");

foreach (var name in names)
    Console.WriteLine(name.Length);

4. Generic `T?` that isn't nullable

static T? FindFirst<T>(List<T> items, Func<T, bool> match)
{
    foreach (var item in items)
        if (match(item)) return item;
    return default;
}

var ids = new List<int> { 3, 7, 0 };
Console.WriteLine($"first id == 0:  {FindFirst(ids, id => id == 0)}");
Console.WriteLine($"first id > 100: {FindFirst(ids, id => id > 100)}");

first id == 0:  0
first id > 100: 0

"Found 0" and "found nothing" print the same thing. When T is unconstrained and you call it with a value type like int, T? is just int, not int?. default is 0. (You can't even check is null on it; that doesn't compile.)

Fix: return whether you found something separately, with the Try pattern.

static bool TryFindFirst<T>(List<T> items, Func<T, bool> match, out T found)
{
    foreach (var item in items)
        if (match(item)) { found = item; return true; }
    found = default!;
    return false;
}

var hasZero = TryFindFirst(ids, id => id == 0, out var zero);
var hasBig  = TryFindFirst(ids, id => id > 100, out var big);
Console.WriteLine(hasZero ? $"found {zero}" : "not found");
Console.WriteLine(hasBig  ? $"found {big}"  : "not found");

found 0
not found

5. The warning everyone scrolls past

This one the compiler does catch:

string? coupon = FindCoupon("WELCOME");

Console.WriteLine(coupon.Length);  // the compiler warns here...

warning CS8602: Dereference of a possibly null reference.

But it's a warning. The build succeeds, and at runtime:

Unhandled exception. System.NullReferenceException: Object reference not set to an instance of an object.

Fix: make nullable warnings errors, so this can't be merged.

<WarningsAsErrors>nullable</WarningsAsErrors>

error CS8602: Dereference of a possibly null reference.

The build fails.

Recap

! silences the compiler; it doesn't prevent null. Treat each one as a code-review question.
Deserializers ignore annotations by default. Use RespectNullableAnnotations and required.
Arrays of reference types start as nulls. Prefer lists, or fill every slot.
Unconstrained T? with a value type is just T. Use the Try pattern.
Make nullable warnings errors.

Which of these have you hit? I'd guess number 2 is the most common in real APIs. Tell me in the comments.

I make short, tested videos about C# bugs that compile fine and still break things. More on the Naze Code YouTube channel.

Sources: Microsoft Learn, Nullable reference types, Respect nullable annotations in System.Text.Json, Required properties, Unconstrained type parameters. Tested on .NET SDK 10.0.302.

What if the garbage collector never runs? 5 C# GC experiments

Naze Code — Sun, 11 Oct 2026 13:25:06 +0000

Most C# developers never think about the garbage collector, until a service's memory climbs all day, or someone adds GC.Collect() "to be safe". So I ran five experiments to see what it actually does.

Machine: .NET 10.0.10, Windows 11, Release build, workstation GC. Each test ran in its own fresh process, three times; ranges are from those three runs.

1. A hundred million objects of garbage

int gen0 = GC.CollectionCount(0);
int gen1 = GC.CollectionCount(1);
int gen2 = GC.CollectionCount(2);
var timer = Stopwatch.StartNew();

for (var i = 0; i < 100_000_000; i++)
{
    var box = new Box(i);          // garbage immediately
}

Console.WriteLine($"100,000,000 objects in {timer.ElapsedMilliseconds} ms");
Console.WriteLine($"gen0 collections: {GC.CollectionCount(0) - gen0}");
Console.WriteLine($"gen1 collections: {GC.CollectionCount(1) - gen1}");
Console.WriteLine($"gen2 collections: {GC.CollectionCount(2) - gen2}");

100,000,000 objects in 180 ms
gen0 collections: 183
gen1 collections: 1
gen2 collections: 0

(180–247 ms over three runs.) A hundred million allocations in about a fifth of a second, and the GC ran 183 times without me noticing.

The .NET GC is generational. New objects start in generation 0, and a gen0 collection only has to deal with what's still alive there. Here, almost nothing is still alive, so each collection is tiny. Short-lived garbage is the cheapest kind of memory you can use.

2. Keep everything

Now the opposite: never let anything become garbage. This test runs with the heap capped at 256 MB (DOTNET_GCHeapHardLimit), so it fails quickly instead of eating the machine's RAM.

// launched with DOTNET_GCHeapHardLimit = 256 MB
var keep = new List<Box>();
try
{
    while (true) keep.Add(new Box(keep.Count));
}
catch (OutOfMemoryException)
{
    var count = keep.Count;
    keep = null!;
    Console.WriteLine($"Out of memory after {count:N0} objects");
}

Out of memory after 7,874,433 objects

About 7.9 million small objects fill 256 MB (each one plus its slot in the list is roughly 32 bytes). The GC was running the whole time; it just couldn't free anything, because every object was still reachable from keep.

That's what a "memory leak" is in .NET: not memory the GC forgot, but references you forgot. A static list, a cache with no eviction, an event handler that's never unsubscribed.

3. Turning the GC off

.NET lets you ask for a stretch of code with no collections at all:

GC.TryStartNoGCRegion(200_000_000);          // "don't collect for 200 MB"
var before = GC.CollectionCount(0);

var keep = new Box[1_000_000];
for (var i = 0; i < keep.Length; i++) keep[i] = new Box(i);

Console.WriteLine($"collections inside region: {GC.CollectionCount(0) - before}");
GC.EndNoGCRegion();

collections inside region: 0

It works, as long as you stay inside the budget. (The counter starts after entering the region, because entering it can trigger one collection first.)

Now give it a 10 MB budget and allocate about 32 MB:

GC.TryStartNoGCRegion(10_000_000);           // only 10 MB this time

var keep = new Box[1_000_000];               // ~32 MB of objects
for (var i = 0; i < keep.Length; i++) keep[i] = new Box(i);

GC.EndNoGCRegion();

Unhandled exception. System.InvalidOperationException: NoGCRegion mode must be set.

No warning when the budget ran out. The region quietly ended, the GC collected as usual, and the only sign was the exception at the very end, when there was no region left to end.

4. Small collection vs full collection

With 5 million long-lived objects on the heap:

var timer = Stopwatch.StartNew();
GC.Collect(0);
Console.WriteLine($"gen0 collection: {timer.Elapsed.TotalMilliseconds:0.00} ms");

timer.Restart();
GC.Collect(2);
Console.WriteLine($"full collection: {timer.Elapsed.TotalMilliseconds:0.00} ms");

gen0 collection: 2.30 ms
full collection: 32.60 ms

(2.30–2.68 ms vs 32.60–33.84 ms.) A full collection has to walk every live object, so it took about 14 times longer. The more long-lived data you keep around, the more each full GC costs.

5. Calling `GC.Collect()` "to be safe"

A thousand small work items, with a realistic heap of a million live objects. Once letting the GC decide, once with GC.Collect() after every item:

var timer = Stopwatch.StartNew();
Work(forceGc: false);
Console.WriteLine($"let the GC decide:     {timer.ElapsedMilliseconds} ms");

timer.Restart();
Work(forceGc: true);                          // GC.Collect() after every item
Console.WriteLine($"GC.Collect() each time: {timer.ElapsedMilliseconds} ms");

let the GC decide:     1 ms
GC.Collect() each time: 6839 ms

(6,839–6,921 ms over three runs.) One millisecond versus about seven seconds. GC.Collect() forces a full, blocking collection every time, which is the expensive kind from part 4, a thousand times over.

Recap

Short-lived objects are cheap; generational GC is built for them.
Leaks in .NET are references you kept, not memory the GC missed.
A no-GC region ends silently when you exceed its budget.
Full collections cost more the more long-lived data you hold.
Don't call GC.Collect(). Let the GC decide.

What's the weirdest memory issue you've had to track down in .NET? Tell me in the comments.

I make short, tested videos about C# and what happens when you measure it. More on the Naze Code YouTube channel.

Sources: Microsoft Learn, Fundamentals of garbage collection, GC.TryStartNoGCRegion, GC.EndNoGCRegion, GC configuration settings. Tested on .NET 10.0.10, Windows 11, Release build, 3 runs each.

C# records, structs and equality: what == really compares

Naze Code — Sun, 11 Oct 2026 13:25:02 +0000

== looks like the simplest operator in C#. But what it compares depends on what you're comparing, and records, which were supposed to make equality "just work", have a couple of edges that bite in real code.

Four small experiments, each run for real on .NET 10 (Release build).

1. Class vs record

public class UserClass(string name, string email)
{
    public string Name { get; } = name;
    public string Email { get; } = email;
}

public record UserRecord(string Name, string Email);

var a = new UserClass("Ada", "ada@x.dev");
var b = new UserClass("Ada", "ada@x.dev");
Console.WriteLine($"class:  {a == b}");

var c = new UserRecord("Ada", "ada@x.dev");
var d = new UserRecord("Ada", "ada@x.dev");
Console.WriteLine($"record: {c == d}");

class:  False
record: True

For a class, == asks "is this the same object?" Two separate objects with identical data are not equal.

For a record, the compiler generates Equals, GetHashCode, == and != for you, and they compare each field. Same data, equal records. That's the main reason to use a record for data like DTOs, messages and value objects.

2. A record holding a list

public record Order(string Customer, List<string> Items);

var first  = new Order("Ada", ["laptop", "mouse"]);
var second = new Order("Ada", ["laptop", "mouse"]);

Console.WriteLine($"Equal? {first == second}");

Equal? False
Items equal? False · same contents? True

Same customer and same items, but not equal. Record equality compares each field with that field type's own equality. string compares by value, but List<string> is a class, so its equality is reference equality. Two different lists with the same contents aren't "equal" to it.

Takeaway: a record is only value-equal "all the way down" if its fields are. For collections, either compare them yourself (SequenceEqual), or override Equals in the record. Don't assume it.

3. `with` makes a shallow copy

var original = new Order("Ada", ["laptop"]);
var copy = original with { Customer = "Bob" };

copy.Items.Add("headphones");

Console.WriteLine($"Bob's items: {string.Join(", ", copy.Items)}");
Console.WriteLine($"Ada's items: {string.Join(", ", original.Items)}");

Bob's items: laptop, headphones
Ada's items: laptop, headphones

with copies each field's value. For a list, the value is a reference, so Bob's order and Ada's order now share the same list. Adding to one adds to both.

Takeaway: if a record holds something mutable, with doesn't protect you. Give the copy its own new list when you use with, or use immutable collections in records.

4. The struct whose `Equals` allocates

Two structs with the same fields, one a plain struct, one a record struct:

public struct Point
{
    public string Label;
    public int X, Y;
}

public record struct PointRecord(string Label, int X, int Y);

Search a list of 2,000 of each, 1,000 times, for an item that isn't there:

var timer = Stopwatch.StartNew();
for (var i = 0; i < 1_000; i++)
    points.Contains(new Point { Label = "p", X = -1, Y = -1 });
Console.WriteLine($"struct:        {timer.ElapsedMilliseconds} ms");

timer.Restart();
for (var i = 0; i < 1_000; i++)
    records.Contains(new PointRecord("p", -1, -1));
Console.WriteLine($"record struct: {timer.ElapsedMilliseconds} ms");

struct:        244 ms
record struct: 16 ms
allocated per Contains over 2,000 items: struct 320,000 B · record struct 0 B

About 15 times slower, and 320 KB of garbage for a single Contains call (160 bytes per comparison).

A plain struct that doesn't override Equals gets ValueType.Equals. When the struct contains a reference-type field (the string here), that default implementation falls back to reflection to compare the fields, boxing as it goes. A record struct gets a generated, field-by-field Equals instead, with no reflection and no allocations.

Takeaway: if you put structs in lists, dictionaries or hash sets, make them record structs, or implement IEquatable<T> yourself.

Recap

Class == compares references. Record == compares fields.
Record equality is only as deep as its fields' equality; lists compare by reference.
with copies references, so mutable fields end up shared.
A plain struct's default Equals can use reflection and allocate. Use record struct or IEquatable<T>.

Have you been bitten by record equality on a collection? Tell me in the comments.

I make short, tested videos about C# and what's really going on under the hood. More on the Naze Code YouTube channel.

Sources: Microsoft Learn, Records, ValueType.Equals (remarks on reflection), with expression. Tested on .NET SDK 10.0.302, Release build. Timings are from one run; the research runs ranged 229–258 ms vs 16–17 ms.

5 C# DateTime bugs that pass every test

Naze Code — Sun, 11 Oct 2026 07:28:17 +0000

Date and time bugs are the worst kind: the code is correct on the day you test it, in the time zone you test it in. Then the clocks change, or a user in another country logs in, or the CI server runs on a Sunday.

Here are five, each replayed for real on .NET 10. The machine running them is set to UTC+8 (no daylight saving). That detail matters for two of them, which is exactly the point.

1. Subtracting local times across a clock change

// Night shift in New York, the night the clocks jump forward
var start = new DateTime(2026, 3, 8, 1, 0, 0);
var end   = new DateTime(2026, 3, 8, 4, 0, 0);

var hours = (end - start).TotalHours;
Console.WriteLine($"Hours paid: {hours}");

Hours paid: 3

On that night in New York, the clock goes from 1:59 straight to 3:00. 2 AM never happens. The shift lasted two real hours, but subtracting wall-clock times knows nothing about that, so it pays three.

Fix: convert both ends to UTC in the right time zone, then subtract.

var ny = TimeZoneInfo.FindSystemTimeZoneById("America/New_York");

var hours = (TimeZoneInfo.ConvertTimeToUtc(end, ny)
           - TimeZoneInfo.ConvertTimeToUtc(start, ny)).TotalHours;

Hours paid: 2

The opposite night in November is harder: 1 AM happens twice, and a plain DateTime can't say which one it means. ConvertTimeToUtc treats an ambiguous time as standard time, so for those shifts you need to record the offset when the time is captured, not reconstruct it later.

2. `DateTime.Parse` and the vanishing `Z`

var json = "2026-10-12T09:00:00Z";      // 9 AM UTC, from the API

var meeting = DateTime.Parse(json);
Console.WriteLine($"Meeting: {meeting:HH:mm} ({meeting.Kind})");

Meeting: 17:00 (Local)

The Z means UTC. DateTime.Parse honors it by converting to the machine's local time zone and marking the result Local. On a UTC+8 machine, 9 AM becomes 5 PM. On a machine set to UTC, local time is UTC, so the bug is invisible there.

Fix: parse into DateTimeOffset, which keeps the offset that was in the string.

var meeting = DateTimeOffset.Parse(json, CultureInfo.InvariantCulture);
Console.WriteLine($"Meeting: {meeting:HH:mm} (offset {meeting.Offset})");

Meeting: 09:00 (offset 00:00:00)

3. `==` that ignores time zones

var deadlineUtc = new DateTime(2026, 10, 12, 9, 0, 0, DateTimeKind.Utc);
var nowLocal    = new DateTime(2026, 10, 12, 9, 0, 0, DateTimeKind.Local);

Console.WriteLine($"Same moment? {deadlineUtc == nowLocal}");

Same moment? True

On this machine, those two are 8 hours apart. DateTime equality compares the clock reading and ignores Kind completely.

Fix: DateTimeOffset compares actual moments in time.

var deadline = new DateTimeOffset(2026, 10, 12, 9, 0, 0, TimeSpan.Zero);
var now      = new DateTimeOffset(2026, 10, 12, 9, 0, 0, TimeSpan.FromHours(8));

Console.WriteLine($"Same moment? {deadline == now}");

Same moment? False

4. `AddDays` across a clock change

DateTimeOffset fixed traps 2 and 3. But it has its own blind spot (Ny is TimeZoneInfo.FindSystemTimeZoneById("America/New_York")):

// Daily standup, 9 AM New York. Saturday's meeting:
var saturday = new DateTimeOffset(2026, 3, 7, 9, 0, 0, TimeSpan.FromHours(-5));

var sunday = saturday.AddDays(1);
Console.WriteLine($"Sunday: {TimeZoneInfo.ConvertTime(sunday, Ny):HH:mm} New York time");

Sunday: 10:00 New York time

A DateTimeOffset has a fixed offset, not a time zone. AddDays(1) adds exactly 24 hours and keeps -05:00, but by Sunday morning New York has moved to -04:00. So the "9 AM" standup lands at 10.

Fix: do calendar math in wall-clock time, then ask the time zone for that day's offset.

var saturday = new DateTime(2026, 3, 7, 9, 0, 0);

var sundayLocal = saturday.AddDays(1);                  // wall clock: 9 AM
var sunday = new DateTimeOffset(sundayLocal, Ny.GetUtcOffset(sundayLocal));
Console.WriteLine($"Sunday: {sunday:HH:mm} New York time (offset {sunday.Offset})");

Sunday: 09:00 New York time (offset -04:00:00)

5. A test that depends on what day it is

public class Promo
{
    public bool IsWeekendSale() =>
        DateTime.Now.DayOfWeek is DayOfWeek.Saturday or DayOfWeek.Sunday;
}

// Test: "no sale on a weekday"
var promo = new Promo();
Console.WriteLine(promo.IsWeekendSale() ? "FAIL: sale is on" : "PASS");

FAIL: sale is on

I ran it on a Sunday. From Monday to Friday this test passes, so it'll fail for whoever happens to work on a weekend, and nobody will be able to reproduce it on Monday.

Fix: don't read the clock directly; take a TimeProvider (built into .NET 8 and later).

public class PromoWithClock(TimeProvider clock)
{
    public bool IsWeekendSale() =>
        clock.GetLocalNow().DayOfWeek is DayOfWeek.Saturday or DayOfWeek.Sunday;
}

Production passes TimeProvider.System. Tests pass a FakeTimeProvider (from the Microsoft.Extensions.TimeProvider.Testing package) set to whatever moment they need:

var clock = new FakeTimeProvider(
    new DateTimeOffset(2026, 10, 14, 12, 0, 0, TimeSpan.Zero));   // a Wednesday
var promo = new PromoWithClock(clock);
Console.WriteLine(promo.IsWeekendSale() ? "FAIL: sale is on" : "PASS");

PASS

Recap

Durations: convert to UTC in the right time zone before subtracting.
Parse timestamps with an offset into DateTimeOffset, not DateTime.
Compare moments with DateTimeOffset; DateTime == ignores Kind.
Calendar math ("same time tomorrow") in wall-clock time, then get the offset from the time zone.
Inject TimeProvider; never read DateTime.Now inside logic you want to test.

What's the worst date bug you've shipped? Tell me in the comments.

I make short, tested videos about C# bugs that compile fine and still break things. More on the Naze Code YouTube channel.

Sources: Microsoft Learn, Choosing between DateTime, DateTimeOffset and TimeZoneInfo, TimeZoneInfo.ConvertTimeToUtc, TimeProvider, FakeTimeProvider. Tested on .NET SDK 10.0.302, machine set to UTC+8.

Are exceptions really slow in C#? I threw a million to find out

Naze Code — Sun, 11 Oct 2026 07:28:14 +0000

"Exceptions are slow" gets repeated in every C# code review, usually without a number attached. So I measured it. Five experiments, each run three times on an idle machine: .NET 10.0.10, Windows 11, Release build, after a warm-up. The ranges below are from those three runs.

Absolute timings depend a lot on the machine and what else it's doing (the runs in the video below were about twice as slow as these), so focus on the ratios.

1. What does one throw cost?

const int count = 1_000_000;
var timer = Stopwatch.StartNew();

for (var i = 0; i < count; i++)
{
    try { throw new InvalidOperationException("nope"); }
    catch (InvalidOperationException) { }
}

Console.WriteLine($"{count:N0} throws: {timer.ElapsedMilliseconds} ms");
Console.WriteLine($"one throw: {timer.Elapsed.TotalNanoseconds / count:N0} ns");

1,000,000 throws: 959 ms
one throw: 959 ns

About 1 microsecond per throw and catch (950–963 ns over three runs). For a real error that happens once in a while, that's nothing. For something that happens on every request, it adds up fast.

2. Does a `try` block cost anything if nothing throws?

var timer = Stopwatch.StartNew();
for (var i = 0; i < count; i++) sink += Work(i);
Console.WriteLine($"no try:   {timer.ElapsedMilliseconds} ms");

timer.Restart();
for (var i = 0; i < count; i++)
{
    try { sink += Work(i); }
    catch (Exception) { sink--; }
}
Console.WriteLine($"with try: {timer.ElapsedMilliseconds} ms");

100 million calls each:

no try:   82 ms
with try: 102 ms

Three runs: 81–82 ms vs 102–103 ms. So in this tight loop the try version was consistently about 20 ms slower over 100 million calls, which is about 0.2 nanoseconds per call.

That's not zero, and the video called it free, which these runs don't support. But compare it with part 1: one throw costs about 5,000 times more than entering a try. .NET doesn't run any setup code for a try block; the runtime keeps a table of protected regions and only looks at it when something is thrown. Wrapping code in try is not where your time goes.

3. Does it matter how deep the throw is?

static void Dive(int depth)
{
    if (depth == 0) throw new InvalidOperationException("bottom");
    Dive(depth - 1);
}

Throwing from 1, 10 and 50 calls deep, 100,000 times each:

depth  1: 1,176 ns per throw
depth 10: 1,163 ns per throw
depth 50: 1,181 ns per throw

Across three runs, all depths stayed between 1,163 and 1,215 ns, with no trend. At these depths, the number of throws matters, not how far they travel.

4. `int.Parse` + catch vs `int.TryParse`

A million strings that aren't numbers:

var timer = Stopwatch.StartNew();
var bad = 0;
foreach (var text in Inputs)
{
    try { int.Parse(text); }
    catch (FormatException) { bad++; }
}
Console.WriteLine($"Parse + catch: {timer.ElapsedMilliseconds} ms ({bad:N0} bad)");

timer.Restart();
bad = 0;
foreach (var text in Inputs)
    if (!int.TryParse(text, out _)) bad++;
Console.WriteLine($"TryParse:      {timer.ElapsedMilliseconds} ms ({bad:N0} bad)");

Parse + catch: 1434 ms (1,000,000 bad)
TryParse:      3 ms (1,000,000 bad)

Same answer, roughly 480 times faster. This is where "exceptions are slow" is true in practice: using them for an outcome you expect. Bad user input, a missing key or a cache miss isn't exceptional. Use the Try pattern for those.

5. `throw ex` vs `throw`

Not a speed issue, but the most common exception mistake I see:

static void WithThrowEx()
{
    try { SaveOrder(); }
    catch (Exception ex) { throw ex; }
}

static void WithThrow()
{
    try { SaveOrder(); }
    catch (Exception) { throw; }
}

The top two frames of each stack trace:

throw ex: X5.WithThrowEx  <-  X5.Run
throw   : X5.SaveOrder  <-  X5.WithThrow

throw ex restarts the stack trace at the catch, so SaveOrder, the method that actually failed, has disappeared. throw; keeps it. A default dotnet build already warns about it:

warning CA2200: Re-throwing caught exception changes stack information

Recap

One throw costs about a microsecond. Fine for real errors, not for normal control flow.
A try block costs almost nothing when nothing throws (about 0.2 ns per call here).
Depth barely mattered. Throw less, not shallower.
Expected failures belong in TryParse / TryGetValue, not in catch.
Rethrow with throw;, never throw ex;.

Run these on your machine and post your numbers in the comments. I'm curious how much they vary.

I make short, tested videos about C# and what happens when you measure it. More on the Naze Code YouTube channel.

Sources: Microsoft Learn, Best practices for exceptions, Exceptions and performance, CA2200. Tested on .NET 10.0.10, Windows 11, Release build, 3 runs each.

What async/await really compiles to in C# (and when ValueTask is worth it)

Naze Code — Sun, 11 Oct 2026 07:28:11 +0000

Most of us use async/await every day without knowing what it turns into. That's fine, until you need to answer a question like "should this method return ValueTask?" and realize the answer depends on what await actually does.

So let's look. Four small experiments, each run for real on .NET 10 (Release build unless noted), and one practical decision at the end.

1. What runs where, and in what order

Console.WriteLine($"1. caller             thread {Environment.CurrentManagedThreadId}");
var task = LoadAsync();
Console.WriteLine($"3. caller continues   thread {Environment.CurrentManagedThreadId}");
await task;

static async Task LoadAsync()
{
    Console.WriteLine($"2. LoadAsync starts   thread {Environment.CurrentManagedThreadId}");
    await Task.Delay(100);
    Console.WriteLine($"4. after the await    thread {Environment.CurrentManagedThreadId}");
}

1. caller             thread 2
2. LoadAsync starts   thread 2
3. caller continues   thread 2
4. after the await    thread 5

Two things people often get wrong:

Calling an async method doesn't start a new thread. LoadAsync runs synchronously, on the caller's thread, right up to its first await of something that isn't finished yet.
At that await, the method returns to the caller (line 3) with an unfinished Task. When the delay completes, the rest of the method runs. In a console app there's no UI thread to return to, so it ran on a thread pool thread (5 here; it could also happen to be the same one).

2. The class (or struct) the compiler writes for you

Take an ordinary async method:

public static async Task<int> CountOrdersAsync(int id)
{
    var user = await GetUserAsync(id);
    var orders = await GetOrdersAsync(user);
    return orders;
}

The compiler rewrites it into a hidden type. Reflection can find it:

var machine = typeof(Shop).GetNestedTypes(BindingFlags.NonPublic)
    .Single(t => t.Name.Contains("CountOrdersAsync"));

Console.WriteLine($"{machine.Name}   struct: {machine.IsValueType}");
foreach (var i in machine.GetInterfaces())
    Console.WriteLine($"  implements {i.Name}");
foreach (var f in machine.GetFields(BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic))
    Console.WriteLine($"  {f.FieldType.Name,-24} {f.Name}");

Release build:

<CountOrdersAsync>d__0   struct: True
  implements IAsyncStateMachine
  Int32                    <>1__state
  AsyncTaskMethodBuilder`1 <>t__builder
  Int32                    id
  TaskAwaiter`1            <>u__1
  TaskAwaiter`1            <>u__2

That's the whole trick:

<>1__state remembers which await you're paused at, so the method can resume in the right place.
<>t__builder creates and completes the Task<int> the caller gets.
id is your parameter, kept so it survives across awaits.
<>u__1 and <>u__2 hold the awaiter for each of the two awaits.

Notice that user and orders aren't fields. In Release, the compiler only keeps locals that are still needed after an await.

Debug build, same code:

<CountOrdersAsync>d__0   struct: False
  implements IAsyncStateMachine
  Int32                    <>1__state
  AsyncTaskMethodBuilder`1 <>t__builder
  Int32                    id
  String                   <user>5__1
  Int32                    <orders>5__2
  String                   <>s__3
  Int32                    <>s__4
  TaskAwaiter`1            <>u__1
  TaskAwaiter`1            <>u__2

In Debug it's a class, and every local (plus a couple of compiler temporaries) becomes a field. In Release it's a struct, and it only moves to the heap if the method actually has to pause.

3. The fast path: awaiting something that's already done

var cached = Task.FromResult(42);

Console.WriteLine($"before   thread {Environment.CurrentManagedThreadId}");
var value = await cached;              // already finished
Console.WriteLine($"after    thread {Environment.CurrentManagedThreadId}");

before   thread 5
after    thread 5

await first asks the task "are you already complete?" If yes, it just takes the result and keeps going, with no pause, no scheduling and no thread hop. This fast path is why the next part matters.

4. What each call costs

A price lookup that's almost always served from a cache, written twice, once with each return type:

static async Task<int> GetPriceAsync(int id)       // usually cached
{
    if (Cache.TryGetValue(id, out var price)) return price;
    await Task.Delay(10);
    return 0;
}

static async ValueTask<int> GetPriceValueAsync(int id)
{
    if (Cache.TryGetValue(id, out var price)) return price;
    await Task.Delay(10);
    return 0;
}

Measured with GC.GetTotalAllocatedBytes over 100,000 calls, after a warm-up:

Task<int>, cached            72 bytes per call
ValueTask<int>, cached        0 bytes per call
really waits                 96 bytes per call

Task<int>, cache hit: 72 bytes. The method never pauses, but it still has to hand back a Task<int> object, and that's an allocation. (The runtime caches a few common results, but not arbitrary values like this one.)
ValueTask<int>, cache hit: 0 bytes. A ValueTask is a struct that can carry the result directly, so nothing goes on the heap.
A method that really waits: 96 bytes. When it pauses, the state machine from part 2 has to move to the heap so it can be resumed later. ValueTask doesn't avoid that.

So when is `ValueTask` worth it?

When a method usually completes synchronously (cache hits, buffered reads, already-validated input) and it's called often enough that the allocations matter. That's the one case where it saves real work.

Otherwise, stay with Task. ValueTask comes with rules: await it once, don't store it to await later, and don't await it from two places at once. A Task has none of those restrictions.

Recap

An async method runs synchronously until its first await of something unfinished.
The compiler turns it into a state machine: a state number, a builder, and only the locals that must survive an await.
Awaiting a completed task takes a fast path: no pause, no thread switch.
Task<T> allocates even when nothing waits. ValueTask<T> doesn't, but only use it for hot paths that usually complete synchronously.

Did any of this surprise you? I'd like to hear which part in the comments.

I make short, tested videos about C# and what's going on under the hood. More on the Naze Code YouTube channel.

Sources: Microsoft Learn, Task asynchronous programming model, ValueTask<TResult>; .NET Blog, How async/await really works in C#. Tested on .NET SDK 10.0.302, Release build unless noted.

5 ways Cancel doesn't actually cancel in C#

Naze Code — Sun, 11 Oct 2026 06:28:48 +0000

A user clicks Export, changes their mind, and clicks Cancel. The spinner goes away. On the server, the export keeps running to the end and saves a file nobody wants.

CancellationToken only works if every piece of code along the way cooperates. Here are five ways it quietly doesn't. Each demo logs a timestamp, the "Cancel" click is simulated, and every output is copied from actually running it on .NET 10. (The demo harness prints Cancelled cleanly when the task ends with a cancellation, and (done) when it runs to completion.)

1. Passing the token to `Task.Run` and nowhere else

using var cts = new CancellationTokenSource();
var work = Task.Run(() => BuildReport(), cts.Token);

await Task.Delay(500);
cts.Cancel();                     // user clicks Cancel
Log.Write("Cancel clicked");

await work;

static void BuildReport()
{
    for (var row = 1; row <= Report.Rows; row++)
        Thread.Sleep(300);        // slow work, row by row
    Report.Save(Report.Rows);
}

[0.5s] Cancel clicked
[3.1s] Report saved (10/10 rows)
[3.1s] (done)

Cancelled at half a second, finished anyway at three. The token you give Task.Run is only used to skip the work if it hasn't started yet. Once BuildReport is running, nothing inside it knows about the token.

Fix: pass the token into the work and check it.

var work = Task.Run(() => BuildReport(cts.Token), cts.Token);

static void BuildReport(CancellationToken ct)
{
    for (var row = 1; row <= Report.Rows; row++)
    {
        ct.ThrowIfCancellationRequested();
        Thread.Sleep(300);        // slow work, row by row
    }
    Report.Save(Report.Rows);
}

[0.5s] Cancel clicked
[0.6s] Cancelled cleanly

2. Taking a token and not passing it on

public static async Task<string> LoadPricesAsync(CancellationToken ct)
{
    var prices = await Api.FetchAsync("prices");
    return prices;
}

[0.5s] Cancel clicked
[3.0s] Loaded prices
[3.0s] (done)

The method accepts ct, so it looks cancellable. But FetchAsync, like most .NET APIs, takes the token as an optional parameter, so forgetting it compiles without a word.

Fix: forward it.

var prices = await Api.FetchAsync("prices", ct);

[0.5s] Cancel clicked
[0.5s] Cancelled cleanly

There's an analyzer rule for exactly this, CA2016, but in my test it didn't show up in a normal build until I turned it on in .editorconfig:

dotnet_diagnostic.CA2016.severity = warning

3. Stopping quietly instead of loudly

public static async Task ExportAsync(CancellationToken ct)
{
    var rows = 0;
    while (rows < Report.Rows)
    {
        if (ct.IsCancellationRequested) break;   // stop quietly
        await Task.Delay(300);
        rows++;
    }
    Report.Save(rows);
}

[1.0s] Cancel clicked
[1.2s] Report saved (4/10 rows)
[1.2s] (done)

It did stop, but break drops straight into the code after the loop, which saves a partial report as if it were finished. And the caller sees a normal successful return, so it can't tell the export was cancelled.

Fix: throw, and give the token to the delay too, so a cancel interrupts the wait instead of finishing it.

while (rows < Report.Rows)
{
    ct.ThrowIfCancellationRequested();       // stop loudly
    await Task.Delay(300, ct);
    rows++;
}

[1.0s] Cancel clicked
[1.0s] Cancelled cleanly

4. Catching the wrong exception type

try
{
    await SearchAsync(ct);
}
catch (TaskCanceledException)
{
    Log.Write("Search cancelled");
}

static async Task SearchAsync(CancellationToken ct)
{
    foreach (var page in Enumerable.Range(1, 10))
    {
        ct.ThrowIfCancellationRequested();
        await Pages.LoadAsync(page);
    }
}

[1.0s] Cancel clicked
Unhandled exception. System.OperationCanceledException: The operation was canceled.

Cancellation comes in two exception types. A cancelled Task.Delay (and many async APIs) throws TaskCanceledException. ThrowIfCancellationRequested() throws its base class, OperationCanceledException. Catching the narrower one lets the other crash straight through.

Fix: catch the base class, which covers both.

catch (OperationCanceledException)
{
    Log.Write("Search cancelled");
}

[1.0s] Cancel clicked
[1.2s] Search cancelled
[1.2s] (done)

5. A retry loop that retries cancellation

public static async Task SendWithRetryAsync(CancellationToken ct)
{
    for (var attempt = 1; attempt <= 5; attempt++)
    {
        try
        {
            await Api.SendAsync(ct);
            return;
        }
        catch (Exception e)
        {
            Log.Write($"Attempt {attempt} failed: {e.Message}");
        }
    }
    Log.Write("ALERT: order could not be sent");
}

[0.1s] Attempt 1 failed: A task was canceled.
[0.1s] Cancel clicked
[0.1s] Attempt 2 failed: A task was canceled.
[0.1s] Attempt 3 failed: A task was canceled.
[0.1s] Attempt 4 failed: A task was canceled.
[0.1s] Attempt 5 failed: A task was canceled.
[0.1s] ALERT: order could not be sent
[0.1s] (done)

The user cancelled, and the code treated it as an outage: five instant "failures" and an alert that pages someone. catch (Exception) catches cancellation too.

Fix: an exception filter, so cancellation passes straight through the retry.

catch (Exception e) when (e is not OperationCanceledException)
{
    Log.Write($"Attempt {attempt} failed: {e.Message}");
}

[0.1s] Cancel clicked
[0.1s] Cancelled cleanly

Recap

The token you give Task.Run only prevents the start. Pass it into the work.
Forward the token to every call that accepts one. Turn on CA2016.
ThrowIfCancellationRequested(), not a quiet break.
Catch OperationCanceledException, not TaskCanceledException.
Retry loops must let cancellation through: when (e is not OperationCanceledException).

Which of these is hiding in your codebase right now? Tell me in the comments.

I make short, tested videos about C# bugs that compile fine and still break things. More on the Naze Code YouTube channel.

Sources: Microsoft Learn, Cancellation in managed threads, Task.Run, CA2016, TaskCanceledException. Tested on .NET SDK 10.0.302.

I pushed C# until it broke: 5 hard limits, tested

Naze Code — Sun, 11 Oct 2026 01:37:23 +0000

Every language has edges. Most of the time you never touch them, until a counter goes negative in production or a service dies with no exception in the logs.

So I went looking for C#'s edges on purpose. Five questions, each answered by actually running the code. Machine: .NET 10.0.10, Windows 11, 20 cores, Release build unless stated. Your timings will differ, so treat them as "on my machine".

1. How high can an `int` count?

int counter = 0;
var timer = Stopwatch.StartNew();

while (true)
{
    counter++;
    if (counter < 0) break;   // went past int.MaxValue
}

Console.WriteLine($"Wrapped to {counter:N0} after {timer.Elapsed.TotalSeconds:F2} s");

Wrapped to -2,147,483,648 after 0.47 s

Half a second to count through every positive int, and then it quietly wraps to the most negative one. No exception, no warning. (In a Debug build the same loop took about 1.1 s.)

C# arithmetic is unchecked by default. If an overflow would be a bug, say so:

int counter = int.MaxValue;
counter = checked(counter + 1);   // no silent wrap

Unhandled exception. System.OverflowException: Arithmetic operation resulted in an overflow.

Useful at work: wrap counters, IDs and money-adjacent math in checked, or turn on overflow checking for the whole project with <CheckForOverflowUnderflow>true</CheckForOverflowUnderflow>.

2. How big can an array get?

Console.WriteLine($"Array.MaxLength: {Array.MaxLength:N0}");

var big = new byte[Array.MaxLength];
Console.WriteLine($"Allocated {big.Length / 1e9:F2} GB");

var tooBig = new byte[Array.MaxLength + 1];

Array.MaxLength: 2,147,483,591
Allocated 2.15 GB
Out of memory.

The first allocation worked. The second, just one element bigger, crashed the process. If you catch the exception instead, its message tells the real story: Array dimensions exceeded supported range.

The limit is the number of elements, not memory. Array.MaxLength is the same for every element type (bigger element types can run out of memory sooner).

Useful at work: more than about 2 billion items, or more than ~2 GB in one byte[], means chunking, streams or memory-mapped files, not a bigger array.

3. How deep can a method recurse?

static int depth = 0;

static void GoDeeper()
{
    depth++;
    if (depth % 1000 == 0) Console.WriteLine($"depth {depth:N0}");
    GoDeeper();
}

try { GoDeeper(); }
catch (Exception e) { Console.WriteLine($"Caught: {e.Message}"); }

depth 15,000
depth 16,000
Stack overflow.

About sixteen thousand calls deep, for this method's frame size. And notice what's missing: Caught: never printed. A stack overflow can't be caught in .NET. The process is simply terminated.

The depth depends on the stack size, so a thread with a bigger stack goes much further:

var thread = new Thread(GoDeeper, maxStackSize: 256 * 1024 * 1024);
thread.Start();
thread.Join();

depth 2,794,000
depth 2,795,000
Stack overflow.

Useful at work: a bigger stack only moves the cliff. If input depth isn't under your control (deep JSON, user-built trees), use a loop with an explicit Stack<T> instead of recursion.

4. A million tasks vs ten thousand threads

var timer = Stopwatch.StartNew();
var tasks = new List<Task>();

for (int i = 0; i < 1_000_000; i++)
    tasks.Add(Task.Delay(1000));

await Task.WhenAll(tasks);
Console.WriteLine($"1,000,000 one-second waits took {timer.Elapsed.TotalSeconds:F2} s");

1,000,000 one-second waits took 1.43 s
peak working set: 227 MB

One after another, those waits would take a million seconds, about 11.6 days. Run as tasks, they finished in under a second and a half. A waiting task doesn't hold a thread; it's just a small object and a timer.

Now the same idea with real threads, a hundred times fewer of them:

var timer = Stopwatch.StartNew();
var threads = new List<Thread>();

for (int i = 0; i < 10_000; i++)
{
    var t = new Thread(() => Thread.Sleep(1000));
    t.Start();
    threads.Add(t);
}

threads.ForEach(t => t.Join());
Console.WriteLine($"10,000 threads took {timer.Elapsed.TotalSeconds:F2} s");

10,000 threads took 1.50 s
peak working set: 321 MB

Ten thousand threads worked here, but they used more memory than a million tasks.

To be precise about what this shows: waiting is cheap with tasks. It doesn't mean a million pieces of CPU work would finish in 1.4 seconds.

Useful at work: for I/O (HTTP calls, database queries, timers), use async/await and let tasks wait. Don't dedicate a thread to each waiting job.

5. A float that can't add 1

float big = 16_777_216f;

Console.WriteLine(big + 1 == big);
Console.WriteLine(0.1 + 0.2 == 0.3);
Console.WriteLine(0.1 + 0.2);

True
False
0.30000000000000004

16,777,216 is 2²⁴. A float has 24 bits of precision, so above that number it can only hold even integers. Adding 1 rounds straight back down:

16777216 -> 16777216
16777217 -> 16777216  (rounded)
16777218 -> 16777218
16777219 -> 16777220  (rounded)

And 0.1 has no exact binary representation, which is why 0.1 + 0.2 isn't 0.3 in C#, or in most languages.

decimal stores base-10 digits, so:

decimal a = 0.1m, b = 0.2m;

Console.WriteLine(a + b == 0.3m);

True

Useful at work: decimal for money. Never compare float/double with ==; compare with a tolerance.

Recap

int overflow is silent. Use checked where it matters.
Arrays cap at 2,147,483,591 elements, whatever your RAM.
Stack overflows can't be caught. Turn deep recursion into a loop.
Waiting is cheap with tasks, expensive with threads.
float and double approximate. decimal for money.

Try any of these on your machine and post your numbers in the comments. I'm curious how much they vary.

I make short, tested videos about C# and what happens when you push it. More on the Naze Code YouTube channel.

Sources: Microsoft Learn, Array.MaxLength, checked and unchecked, StackOverflowException. Tested on .NET 10.0.10 (SDK 10.0.302), Windows 11, Release build.

5 C# habits that catch bugs before production

Naze Code — Sun, 11 Oct 2026 00:39:20 +0000

None of these are clever tricks. They're small habits that turn bugs you'd find in production into bugs you find while typing. Each one is shown as naive code, the bug it hides, and the refactor. Every output is copied from actually running the demo on .NET 10.

1. Don't let work happen "just because you touched it"

public static class Db
{
    public static Connection Conn { get; }

    // Runs the first time ANYTHING touches Db
    static Db()
    {
        Console.WriteLine("Connecting to PROD database...");
        Conn = new Connection(Config.ConnectionString);
    }

    public static string CleanName(string name) =>
        name.Trim().ToLowerInvariant();
}

Someone only wants the string helper:

Db.CleanName("  Bob ");

Connecting to PROD database...
bob

A static constructor runs the first time any member of the type is used, so tidying a name opened a production connection. In a unit test, that's a test talking to prod.

Fix: keep helpers free of side effects, and create expensive things explicitly in one place, your entry point.

public static class Names
{
    public static string Clean(string name) =>
        name.Trim().ToLowerInvariant();
}

public static class Program
{
    public static void Main()
    {
        using var db = new Connection(Config.ConnectionString);
        var users = new UserService(db);
        users.PrintActiveUsers();
    }
}

A detail I tripped over while testing: a plain static readonly field initializer did not run in this situation. Without an explicit static constructor, the runtime is allowed to initialize the type lazily. The explicit static Db() is what makes it run on first touch.

2. Flatten nested ifs with guard clauses

void ProcessSignup(User user)
{
    if (user.Age >= 18)
    {
        if (!blacklist.Contains(user.Email))
        {
            if (user.Email.Contains('@') && user.Name.Length > 1)
            {
                Console.WriteLine($"Welcome, {user.Name}!");
                Database.Save(user);
            }
            else Console.WriteLine("Invalid details");
        }
        else Console.WriteLine("Blocked");
    }
    else Console.WriteLine("Too young");
}

It works, but every else is far away from the if it belongs to, which is where "wrong message for the wrong case" bugs come from.

Fix: reject early, and give each rule a name.

void ProcessSignup(User user)
{
    if (!IsAdult(user))         { Reject("Too young"); return; }
    if (IsBlacklisted(user))    { Reject("Blocked"); return; }
    if (!HasValidDetails(user)) { Reject("Invalid details"); return; }

    Welcome(user);
}

static bool IsAdult(User u) => u.Age >= 18;

bool IsBlacklisted(User u) => blacklist.Contains(u.Email);

static bool HasValidDetails(User u) =>
    u.Email.Contains('@') && u.Name.Length > 1;

Both versions give the same answer for the same user (Too young for a 17-year-old in the demo). The second one reads top to bottom like the business rules.

3. Let the compiler find your nulls

string GetDisplayName(int userId)
{
    User user = _repo.Find(userId); // null if not found

    return user.FirstName + " " + user.LastName;
}

Ask for a user that doesn't exist:

System.NullReferenceException: Object reference not set to an instance of an object.

Turn on nullable reference types and mark the return value as User?:

<Nullable>enable</Nullable>

Now the build points at the exact line:

warning CS8602: Dereference of a possibly null reference.

Fix: handle the case the compiler found.

string GetDisplayName(int userId)
{
    User? user = _repo.Find(userId); // null if not found
    if (user is null) return "Unknown user";

    return $"{user.FirstName} {user.LastName}";
}

Unknown user

To make sure nobody ignores these warnings, promote them to errors:

<WarningsAsErrors>Nullable</WarningsAsErrors>

4. `using` instead of remembering `Dispose()`

public static string ReadFirstLine(string path)
{
    var reader = new StreamReader(path);
    string? line = reader.ReadLine();
    if (line is null)
        throw new InvalidDataException("File is empty");

    reader.Dispose();
    return line;
}

Call it on an empty file, then try to delete that file. On Windows:

System.IO.IOException: The process cannot access the file '...\Temp\empty-report.txt' because it is being used by another process.

(Path shortened.) The throw skips reader.Dispose(), so the file stays locked.

Fix: a using declaration disposes on every exit: return, throw, anything.

public static string ReadFirstLine(string path)
{
    using var reader = new StreamReader(path);
    string? line = reader.ReadLine();
    if (line is null)
        throw new InvalidDataException("File is empty");

    return line;
}

good: deleted fine

I expected code analysis rule CA2000 to flag the first version. With default settings, in my test, it didn't. So don't count on the analyzer here; make using the habit.

5. Say what you want with LINQ

var result = new List<string>();
foreach (var order in orders)
{
    if (order.Total > 100 && !order.IsCancelled)
    {
        result.Add(order.Customer.ToUpper());
    }
}
result.Sort();

Refactor:

var result = orders
    .Where(o => o.Total > 100 && !o.IsCancelled)
    .Select(o => o.Customer.ToUpper())
    .Order()
    .ToList();

AMY, ZOE
AMY, ZOE

Both print the same thing, and in the second each line is one step: filter, transform, sort. To be honest about it: LINQ is about readability, not speed. In C# a hand-written loop is often as fast or faster, so measure before using LINQ in a hot path.

Recap

No hidden work in static constructors. Create expensive things explicitly in Main.
Guard clauses and named rules instead of nested ifs.
<Nullable>enable</Nullable>, and make the warnings errors.
using var for anything disposable.
LINQ for readable data pipelines. Measure the hot paths.

Which habit would you add to this list? Tell me in the comments.

I make short, tested videos about C# bugs that compile fine and still break things. More on the Naze Code YouTube channel.

Tested on .NET SDK 10.0.302. The file-locking result in habit 4 is Windows-specific.

5 LINQ traps that look harmless (with real output)

Naze Code — Sun, 11 Oct 2026 00:39:16 +0000

LINQ reads like plain English, which is exactly why these slip through code review. Each snippet below compiles without a warning. Every output is copied from actually running it on .NET 10.

1. The query that runs later than you think

var prices = new List<int> { 10, 20, 30 };
var cheap  = prices.Where(p => p < 25);

prices.Add(5);
prices.Remove(10);

Console.WriteLine(string.Join(", ", cheap));

You'd expect 10, 20. It prints:

20, 5

Where doesn't run when you write it. It runs when something reads cheap, and by then the list has changed.

Fix: if you want a snapshot, take one.

var cheap = prices.Where(p => p < 25).ToList();

10, 20

Deferred execution is a feature, not a bug. Just choose it on purpose.

2. The query that runs twice

LoadUsers() stands in for a database call and prints a line each time it actually runs:

var active = LoadUsers().Where(u => u.IsActive);

Console.WriteLine($"{active.Count()} active users");

foreach (var u in active)
    Console.WriteLine(u.Name);

Querying database...
2 active users
Querying database...
Ada
Lin

Count() runs the query once, and the foreach runs it again. With EF Core, each one is a real round trip to the database, and the two can even disagree if the data changed in between.

Fix: materialize once, then reuse.

var active = LoadUsers().Where(u => u.IsActive).ToList();

Console.WriteLine($"{active.Count} active users");

Querying database...
2 active users
Ada
Lin

3. `First()` when nothing matches

var admin = users.First(u => u.IsAdmin);

Console.WriteLine($"Notify {admin.Email}");

System.InvalidOperationException: Sequence contains no matching element

First assumes a match exists. When "none" is a normal case, it's the wrong method.

Fix: FirstOrDefault plus a null check.

User? admin = users.FirstOrDefault(u => u.IsAdmin);
if (admin is null)
{
    Console.WriteLine("No admin to notify");
    return;
}

No admin to notify

Careful with value types, though. "Not found" becomes the default value, which looks like real data:

int[] scores = [72, 85, 91];
var firstFail = scores.FirstOrDefault(s => s < 50);
Console.WriteLine($"First failing score: {firstFail}");

First failing score: 0

Nobody scored 0. That's default(int).

4. `Count() > 0` to ask "is there any?"

A log file with a million lines, where the first error is on line 3:

var errors = ReadLogLines().Where(IsError);

if (errors.Count() > 0)
    Console.WriteLine("Something went wrong");

Something went wrong
lines read: 1,000,000

Count() has to read everything to give you a number you then throw away.

Fix: ask the question you mean.

if (errors.Any())
    Console.WriteLine("Something went wrong");

Something went wrong
lines read: 3

To be fair: on a List<T>, Count() is instant because it uses the list's own count. This trap is about lazy queries, streams and database queries.

5. Removing items while looping over them

Four orders, two of them cancelled:

foreach (var order in orders.Where(o => o.IsCancelled))
{
    orders.Remove(order);
}

System.InvalidOperationException: Collection was modified; enumeration operation may not execute.
orders left: 3

The worst part is the last line. It crashed after removing the first cancelled order, so your data is now half cleaned up.

Fix: let the list do it.

orders.RemoveAll(o => o.IsCancelled);

orders left: 2 (#1, #3)

Recap

LINQ queries run when they're read. Use .ToList() when you need a snapshot.
Don't enumerate the same lazy query twice.
First means "this must exist". Otherwise use FirstOrDefault, and watch value types.
Any() to ask "is there at least one?"
Never modify a list you're looping over. RemoveAll exists.

Which of these has cost you the most debugging time? Tell me in the comments.

I make short, tested videos about C# bugs that compile fine and still break things. More on the Naze Code YouTube channel.

Sources: Microsoft Learn, Introduction to LINQ queries, Enumerable.First, Enumerable.Any, How EF Core queries work. Tested on .NET SDK 10.0.302.

DEV Community: Naze Code

How big is Hello World in C#? From 76 MB down to 0.73 MB

1. Default: 0.16 MB, but it isn't the whole story

2. Self-contained: 76.63 MB, 191 files

3. Trimmed single file: 12.30 MB, one file

4. Native AOT: 1.06 MB, 7 ms

5. Native AOT tuned for size: 0.73 MB

Which one should you use?

Why LINQ is lazy: IEnumerable and yield in C#, explained by running it

1. Nothing runs until someone asks

2. What the compiler turns yield into

3. Infinite sequences and early stops

4. The argument check that runs too late

Recap

5 ways null gets past C# nullable reference types

1. The ! that only silences the compiler

2. JSON that doesn't read your annotations

3. Arrays start full of nulls

4. Generic T? that isn't nullable

5. The warning everyone scrolls past

Recap

What if the garbage collector never runs? 5 C# GC experiments

1. A hundred million objects of garbage

2. Keep everything

3. Turning the GC off

4. Small collection vs full collection

5. Calling GC.Collect() "to be safe"

Recap

C# records, structs and equality: what == really compares

1. Class vs record

2. A record holding a list

3. with makes a shallow copy

4. The struct whose Equals allocates

Recap

5 C# DateTime bugs that pass every test

1. Subtracting local times across a clock change

2. DateTime.Parse and the vanishing Z

3. == that ignores time zones

4. AddDays across a clock change

5. A test that depends on what day it is

Recap

Are exceptions really slow in C#? I threw a million to find out

1. What does one throw cost?

2. Does a try block cost anything if nothing throws?

3. Does it matter how deep the throw is?

4. int.Parse + catch vs int.TryParse

5. throw ex vs throw

Recap

What async/await really compiles to in C# (and when ValueTask is worth it)

1. What runs where, and in what order

2. The class (or struct) the compiler writes for you

3. The fast path: awaiting something that's already done

4. What each call costs

So when is ValueTask worth it?

Recap

5 ways Cancel doesn't actually cancel in C#

1. Passing the token to Task.Run and nowhere else

2. Taking a token and not passing it on

3. Stopping quietly instead of loudly

4. Catching the wrong exception type

5. A retry loop that retries cancellation

Recap

I pushed C# until it broke: 5 hard limits, tested

1. How high can an int count?

2. How big can an array get?

3. How deep can a method recurse?

4. A million tasks vs ten thousand threads

5. A float that can't add 1

Recap

5 C# habits that catch bugs before production

1. Don't let work happen "just because you touched it"

2. Flatten nested ifs with guard clauses

3. Let the compiler find your nulls

4. using instead of remembering Dispose()

5. Say what you want with LINQ

Recap

5 LINQ traps that look harmless (with real output)

1. The query that runs later than you think

2. The query that runs twice

3. First() when nothing matches

2. What the compiler turns `yield` into

1. The `!` that only silences the compiler

4. Generic `T?` that isn't nullable

5. Calling `GC.Collect()` "to be safe"

3. `with` makes a shallow copy

4. The struct whose `Equals` allocates

2. `DateTime.Parse` and the vanishing `Z`

3. `==` that ignores time zones

4. `AddDays` across a clock change

2. Does a `try` block cost anything if nothing throws?

4. `int.Parse` + catch vs `int.TryParse`

5. `throw ex` vs `throw`

So when is `ValueTask` worth it?

1. Passing the token to `Task.Run` and nowhere else

1. How high can an `int` count?

4. `using` instead of remembering `Dispose()`

3. `First()` when nothing matches

4. `Count() > 0` to ask "is there any?"