Two things a .NET quote almost never explains

The platform, the language and the web part are three different names

Three words here get used as though they meant the same thing.

.NET is the platform: the runtime that executes the code, plus a large library of ready-made parts. C# is the language a developer types. ASP.NET Core is the piece that answers web requests, so it's what a site or an API is built on. F# and Visual Basic run there too, but a quote saying .NET without naming a language means C#.

The category is the one Java, Node.js and Python occupy: what runs on a computer you rent, holding the rules and the records behind whatever a visitor sees. A proposal naming .NET has described the back half of the build and nothing about the front.

It stopped being Windows-only, and the old one is still out there

The Windows reputation is real and it's stale. The original .NET Framework arrived in 2002 and ran only on Windows. Microsoft supports it as a component of Windows now rather than developing it further.

In 2016 came a ground-up rewrite, .NET Core, which ran on Linux and macOS and was open source under the MIT licence. In November 2020 the naming was tidied up: .NET 5 dropped the Core and became the line everybody means. A major version has landed each November since, with even-numbered releases supported for three years and odd-numbered ones for eighteen months.

So an inherited .NET application sits on the modern line or on the old Framework, and those aren't the same software. Moving between them is a port, not an upgrade.

What it's genuinely good at

Rules. Business software that has a lot of them, applied the same way every time, for years. Java sits in the same seat, and choosing between the two is usually a question about who you can hire rather than about what either platform can do.

The reason is the type system. C# makes a developer say what kind of thing every value is, and the compiler checks that before the code runs. An amount can't quietly turn into a piece of text, and a rename that breaks forty files fails the build instead of failing on a Tuesday afternoon. That's a tax on small changes and a large refund on a codebase somebody else inherits.

Tooling is the other half. Editor, debugger, profiler, test runner, database layer and build system come from one place and work together, so setting them up isn't a project of its own.

It also turns up in banks, insurers, hospitals and government departments, partly because those buyers want a published support window and a named vendor behind it. C# has been among the widely used languages in developer surveys for years, so hiring is realistic, though the pool clusters around large employers.

Azure is the short path, not the only one

Microsoft makes both the platform and the cloud, so they fit together with less work than any other pairing. Deploying to Azure is close to a menu item, and its sign-in, logging and database services expect .NET. If you already run on Microsoft 365, that convenience is real.

It isn't a requirement. Modern .NET runs on Linux, ships in ordinary containers, and AWS and Google Cloud both publish their own .NET libraries and tooling.

What ties you to a cloud isn't the language, it's the managed services the application is built against. One talking to a Postgres database over a standard connection changes host in an afternoon. One built on a provider's own queue, sign-in and serverless functions moves when somebody rewrites it.

Where it stops

The honest ceiling isn't capability. It's weight.

.NET is compiled and typed, and it charges for both up front. There's a build step before anything runs, and a project carries more structure from day one than a script does. On software that will run for years and be touched by people who didn't write it, that's the trade you want. On something you need this month and might throw away in six, you pay the entry price and collect none of it.

So a five-page marketing site is rarely the right home for it. A contact form, a blog, somebody in your own office changing the words on a Wednesday. A content platform already does all of that, and the cheap hosting such a site sits on generally won't run .NET anyway.

And nothing here rescues a badly organised build. The type system catches contradictions. It doesn't catch confusion.

Who has to be around afterwards

This settles more builds than anything technical above it, and proposals leave it out.

.NET expects a developer. Not a big team and not necessarily a full-time one, but somebody who can open the codebase, run it and ship a change. There's no editor a marketing manager signs into to add a page.

The upkeep is light and it's scheduled, which is unusual and helpful. The support window on your version eventually closes, and that upgrade, taken while you're one release behind, is small. Left for years it turns into a project, and that's how a working application gets quoted as a rebuild.

So two names are worth writing down before the platform argument goes any further: who ships a change to this, and who does the upgrade in year two. If both blanks are empty, the platform isn't the question to settle first.