Confessions of a Developer Still Shipping .NET 6 in 2025

What end-of-life really means

When Microsoft declares a runtime “end of life,” the headlines often make it sound like your entire stack is about to collapse. In truth, the reality is less dramatic but still important to understand.

When an open-source tool like .NET has a version that reaches EOL, a few things happen:

• We get no more new features or bug fixes from Microsoft
• There are only limited (or no) security updates
• Say goodbye to official support
• It’s a risk, but not always a showstopper if your codebase is stable.

Which might lead you to the question….

Why I haven’t upgraded yet??

The first reason: dependencies.

A handful of third-party libraries my projects rely on still haven’t fully aligned with .NET 8. Even if the core framework is ready, those gaps create friction, and I’d rather wait for the ecosystem to settle.

The second issue is testing. For small projects, a simple smoke test might be enough, but for larger systems the story is different. A full regression pass across multiple services takes time, coordination, and money. Every migration cycle means rerunning that gauntlet, and unless there’s a clear business win, it can be hard to justify.

There’s also deployment inertia to think about. My work happens in a tightly controlled environment where upgrading a runtime involves policy reviews, compliance checks, and operational approvals.

Lastly, there’s the whole cost vs. ROI calculation. The performance gains and new APIs in .NET 7 and 8 are nice, but so far they haven’t tipped the scale far enough to outweigh the migration burden – at least for my current workloads.

How I “Light Up” on New Runtimes without Forking the Codebase

Instead of trying to detect “.NET version” at runtime, I treat newer features as opt-in compile-time upgrades and keep a single codebase that targets both TFMs. The idea is:

• Multi-target the project (0 and net8.0) so the compiler can include the best code path per target.
• Use #if NET8_0_OR_GREATER (or similar) to call newer APIs, and ship a polyfill or fallback for .NET 6.
• Keep runtime logging so you can confirm what actually booted in prod.
• If a dependency needs a newer version only on .NET 8, use conditional PackageReference.

Project file: multi-targeting with conditional packages 

// IStringSearch.cs
public interface IStringSearch
{
    int IndexOfAny(ReadOnlySpan<char> input, ReadOnlySpan<char> needles);
}

// StringSearch.Fast.cs (included for all TFMs, guarded inside the method)
public sealed class StringSearch : IStringSearch
{
    public int IndexOfAny(ReadOnlySpan<char> input, ReadOnlySpan<char> needles)
    {
#if NET8_0_OR_GREATER
        // .NET 8: use SearchValues for better perf / vectorization
        var sv = System.Buffers.SearchValues.Create(needles);
        return input.IndexOfAny(sv);
#else
        // .NET 6: simple fallback loop (kept tight and allocation-free)
        for (int i = 0; i < input.Length; i++)
        {
            char c = input[i];
            for (int j = 0; j < needles.Length; j++)
            {
                if (c == needles[j])
                    return i;
            }
        }
        return -1;
#endif
    }
}