.NET 10 and C# 14

Microsoft ships a major .NET version annually, alternating between long-term support and standard-term support releases. LTS versions receive three years of support; the intermediate ones considerably less.

For teams this is a planning input rather than trivia. Organisations that track LTS releases upgrade every two years with a supported target. Those that adopt every release spend more time upgrading; those that skip both end up on an unsupported runtime, which becomes a security problem rather than a convenience one.

The consistent direction across recent versions has been less ceremony and stronger guarantees. Expressing intent in fewer lines, with the compiler catching more mistakes — particularly around null handling, which eliminated an entire category of runtime failures for teams that adopted it properly.

The language has also absorbed functional patterns that were once awkward: pattern matching, records for value-like types, expression-bodied members. Modern C# reads noticeably differently from C# of a decade ago, and codebases that have not adopted these patterns feel dated to candidates evaluating an employer.

• Nullable reference types, which remove a whole class of runtime errors
• Pattern matching, replacing chains of type checks and casts
• Records for immutable value-like data
• Reduced ceremony in program structure and member declarations
• Performance-focused features for allocation-sensitive code

The minimal API model made it practical to write a small HTTP service in .NET without the scaffolding the platform was once known for. For microservices and internal tools this removed the main reason teams reached for a different stack.

Controllers remain appropriate for large applications with substantial shared behaviour. The useful judgement is that both are supported and the choice should follow the size and shape of the service rather than fashion.

Sustained runtime investment has made .NET competitive with anything on the managed-runtime spectrum, and ahead of most for throughput-oriented work. This is not marketing — it shows up in independent benchmarking consistently.

Practically this matters for hosting cost. A service handling the same load on less hardware is a smaller monthly bill, and that argument carries weight in architecture discussions where it used to be dismissed.

Running .NET on Linux in containers is now ordinary and well supported rather than a curiosity. Most new deployment is containerised and platform-neutral, and the tooling assumes that.

The residual friction is in older codebases carrying Windows-specific dependencies, and in ecosystem corners where library support is thinner than in more established cross-platform stacks. Both are manageable and worth checking before committing rather than discovering later.

The perception that .NET is a legacy enterprise skill lags the reality by several years, which creates a useful arbitrage: strong demand, steady compensation and less competition than the most fashionable stacks attract.

Sectors with substantial .NET investment — finance, healthcare, insurance, logistics, government — are also sectors with stable employment and real problems. If you value that over working at the newest company, it is a sound position rather than a compromise.

The caution is to avoid being the developer who only knows the framework as it was in 2015. Employers screening C# candidates increasingly ask about async, nullable reference types and modern patterns, and dated answers are noticed.