EXPLAINER

C#

C# is Microsoft's typed language on .NET. Teams use it for Windows services, cross-platform web APIs, Unity games, and Azure backends. It is a strong default when the stack is already Microsoft.

Short answer: C# (C sharp) is the main language of .NET. Use it for APIs, workers and Microsoft-heavy systems, including many Azure services. It is not C or C++, and it is not required for SPFx, which is TypeScript.

What it is

C# ("C sharp") is a statically typed language designed by Microsoft, running on .NET. You compile to IL (intermediate language) and the runtime executes it, historically on Windows and now cross-platform on .NET Core and its successors, just called .NET. ASP.NET Core is the web stack. NuGet is the package feed. The language feels closer to Java than to C or C++: garbage collection, classes, a large standard library, and a team that keeps adding features (records, pattern matching, nullable reference types, async/await).

C# is not SPFx. SharePoint web parts are TypeScript. C# shows up in Microsoft ecosystems as APIs, background workers, desktop tools, game scripts in Unity, and older SharePoint server-side code you should not copy into a new Online tenant.

Why and when it is used

Choose C# when the team and the cloud are already Microsoft: Azure SDKs are idiomatic in C#, identity samples assume it, and hiring in that ecosystem is straightforward. It is a good language for a long-lived API that needs types and a boring deployment. Choose it for Unity if you are making that kind of game.

A small script, a browser UI, or a Python data notebook are the wrong reasons to start a .NET solution. A team that knows Go or Node should not rewrite into C# for an Azure logo. The Azure SDK exists in other languages. Choose C# because the people and the existing code benefit, not because the portal's sample dropdown landed there.

How it works

You install an SDK, create a project (dotnet new), and edit .cs files. dotnet build compiles. dotnet run starts an app. Projects reference NuGet packages via a manifest that should be locked down in CI. Nullable reference types, when enabled, make null a compiler concern similar in spirit to TypeScript's strict nulls. async/await is the normal way to do HTTP and database I/O. LINQ is a fluent way to transform collections and, carefully, to query databases; the careful part is knowing when a LINQ expression became a giant SQL statement.

ASP.NET Core maps routes to functions, uses dependency injection, and reads configuration from environment variables, JSON files and command-line arguments layered together. Entity Framework can map objects to SQL. You should still read the SQL.

Technologies and dependencies

The .NET SDK matching your LTS choice, a code editor, and NuGet. For web APIs, ASP.NET Core. For Azure, the Azure SDK packages you actually call, plus Entra ID libraries if users sign in. Tests use xUnit or NUnit. Containers based on the official runtime images are the usual deploy unit. You do not need Windows to build modern .NET, which surprises people who last saw the stack in 2010.

How to get started

  1. Install the .NET SDK and run dotnet --version.
  2. dotnet new console -n Sample and print a value parsed from JSON using the built-in serialiser.
  3. Enable nullable reference types if the template did not, and fix the warnings instead of suppressing them.
  4. If you need HTTP, dotnet new webapi and one endpoint that reads configuration.
  5. Add a test project and one test that does not need the network.
  6. Call a model API only after the key loads from the environment and never appears in a log.

The dotnet tool is the build. Random clicks in an IDE that invoke a different SDK version are how a teammate gets "works here".

Cautions and trade-offs

Nullable warnings ignored in bulk become noise forever. Turn them on at the start. Async methods that block on .Result deadlock or starve the thread pool; await all the way up. Entity Framework will let you load half the database by accident; profile queries.

Package versions across a solution drift. Centralise them when the solution grows, not on day one. .NET version upgrades are usually smooth and still deserve a test pass. And remember the SharePoint trap: a blog that tells you to deploy a C# farm solution is describing the old server product. For Microsoft 365 sites, the supported UI extension model is SPFx, while C# remains a fine language for the separate service that SPFx calls.