.NET as a platform for web, cloud, desktop, and integrations that need to last

.NET as a platform: why the distinction changes everything

Many developers use .NET as a synonym for ASP.NET Core or Entity Framework.

This is a conceptual mistake that leads to underestimating what .NET truly offers and not exploiting it fully.

.NET is a platform: a runtime, an ecosystem of libraries, a toolchain, and a deployment model that supports web, cloud, desktop, mobile, IoT, AI, and embedded systems.

ASP.NET Core, EF Core, MAUI, ML.NET, Blazor, Orleans: these are all applications that run on this platform, not the platform itself.

This distinction matters because choices made at the platform level influence everything above: the target .NET version, the deployment strategy, the threading model, the runtime optimizations.

Someone who understands .NET as a platform makes more informed decisions at every higher level.

.NET 10, the current LTS version, is a significant maturity milestone: native performance competitive with C and Go in I/O-bound benchmarks, mature tooling, a stable ecosystem, and long-term support.

It no longer needs justification: it is the obvious choice for any greenfield .NET system.

.NET vs other runtimes: when it is the right choice and when it is not

.NET is not the right answer to every problem.

But for a specific family of problems, it is hard to do better.

Where .NET excels: enterprise applications with complex domain logic, high-concurrency web systems, applications that must run on Windows and Linux with the same code, ecosystems already using Azure and Microsoft services, teams that want a single language (C#) for backend, Blazor frontend, MAUI mobile, and automation scripts.

Where alternatives make sense: Node.js for teams that want to unify JavaScript on frontend and backend; Python for data science and ML where the scientific ecosystem dominates; Go for microservices that require minimal footprint and ultra-fast startup; Rust for embedded systems or where memory safety without a GC is a hard requirement.

The criterion is never the preferred technology in the abstract.

It is: which runtime gives the team already existing skills, the necessary libraries, and adequate performance for the expected load, with the lowest maintenance cost over time?

For most enterprise .NET teams, the answer is .NET.

Not out of loyalty, but out of pragmatism.

.NET versioning: STS, LTS, and what to use in production

.NET ships a new version every November.

Even-numbered versions are LTS (Long-Term Support, 3 years of support); odd-numbered versions are STS (Standard-Term Support, 18 months).

In production on enterprise systems the practical rule is: always use the most recent LTS version, unless there are specific reasons not to.

This maximizes the support period without forced updates and guarantees access to the most consolidated runtime optimizations.

Migration between major .NET versions is generally low-trauma thanks to the ecosystem's backward compatibility.

Breaking changes exist but are documented and often concern APIs that have been rare or deprecated since earlier versions.

The tooling (dotnet upgrade-assistant) automates most of the mechanical changes.

The real cost of migration is not changing the target framework: it is updating NuGet dependencies that do not support the new version.

For this reason, keeping dependencies updated version by version is less expensive than doing it in a single jump every three years.

NuGet ecosystem and dependencies: how to manage them without getting lost

NuGet is the largest package ecosystem after npm by package count.

Quality varies enormously: there are libraries maintained by Microsoft and the community with thousands of downloads per day, and there are packages abandoned for years with known vulnerabilities.

The criteria I use to evaluate a NuGet dependency: does it support the target .NET version?

Is it actively maintained?

Does it have known vulnerabilities (checkable with dotnet list package --vulnerable)?

Does it have alternatives maintained by Microsoft or trusted foundations?

Central Package Management, introduced with the .NET SDK, allows centralizing package versions in a Directory.Packages.props file instead of repeating them in every csproj.

In solutions with many projects it is the difference between updating one line and updating fifty.

Transitive dependencies are the silent risk: a package that seems harmless can bring along dependencies with vulnerabilities. dotnet list package --include-transitive --vulnerable is the command to run in every CI pipeline before deploying to production.