C# doesn't run on its own. It runs on .NET, an open-source developer platform that bundles a runtime, a large standard library, and a set of command-line tools. This chapter walks through the pieces of that platform so the acronyms you'll see everywhere (CLR, BCL, SDK, CIL, NuGet) stop feeling like alphabet soup and start meaning something concrete.

.NET is a developer platform maintained by Microsoft and the .NET Foundation. It ships under an open-source license and runs on Windows, Linux, and macOS. When people say ".NET", they're really talking about three things bundled together:

C# is the most popular language on .NET, but it isn't the only one. F# (functional-first) and Visual Basic .NET also compile to the same runtime and share the same libraries. The platform is language-agnostic at the runtime level, which is why code written in any .NET language can call code written in any other.

You'll still see references to ".NET Framework" and ".NET Core" in older blog posts. Here's the short version of how we got to today:

For the rest of this course, when we say ".NET", we mean modern .NET (5 and up, unified). If you ever see a job listing that specifically says ".NET Framework 4.x", that's the older Windows-only platform, and it behaves a little differently. Modern .NET is the forward path.

Think of .NET as a stack. Your C# code sits at the top. Below it, the standard library gives you ready-made building blocks. Below that, the runtime turns your compiled code into something the CPU can execute. At the bottom is the operating system.

Read it top to bottom. Your code calls into the BCL ("give me a List<Product>"). The BCL itself is just more compiled .NET code, so it runs on the CLR. The CLR talks to the operating system to get memory, threads, and system calls. The next few sections look at the middle layers in turn.

The CLR is the engine that runs your code. When you compile a C# program, the output isn't native machine code, it's an intermediate format that the CLR understands. The CLR's job is to take that intermediate code, turn it into instructions your CPU can actually execute, and manage the program while it runs.

It does three big things:

JIT compilation. JIT stands for Just-In-Time. The CLR doesn't translate the whole program upfront. Instead, the first time a method is called, the JIT compiles that method to native code, caches it, and runs it. The next time the same method is called, the cached native code runs directly. That's why C# code often feels slow on the first call and fast on subsequent calls.

Garbage collection (GC). When you create an object with new, the CLR allocates memory for it. When nothing in your program references that object anymore, the garbage collector eventually reclaims that memory and gives it back to the system. You don't call free or delete in C#. The GC handles it.

Type safety and the type system. The CLR knows the type of every object at runtime. If you try to cast a Product to an Order, the CLR catches it and throws an InvalidCastException instead of letting your program corrupt memory. This is what makes C# a memory-safe language.

We'll cover how the compilation actually flows (source -> intermediate code -> JIT -> native) in the _How C# Works (Compilation & Execution)_ lesson. For now, the shape is enough: the CLR is the engine, and JIT, GC, and the type system are its three main moving parts.

The BCL is the standard library that ships with .NET. It's a large collection of types organized into namespaces, and it's what lets you write useful programs without reinventing strings, lists, file readers, HTTP clients, and JSON parsers from scratch.

A handful of namespaces you'll touch constantly:

You don't install any of these. They come with .NET. Pulling them into a file is a one-line using directive (and in .NET 6 and later, many of them are imported globally by default, so you often don't even write the using).

Here's a tiny program that touches two BCL namespaces at once: a generic collection from System.Collections.Generic, and a file reader from System.IO.

Nothing in that snippet is custom. List<string> lives in System.Collections.Generic. File lives in System.IO. Console and string live in System. The whole program is BCL types glued together with a few lines of your own logic.

The BCL is also where modern features live. JSON parsing? System.Text.Json. HTTP requests? System.Net.Http.HttpClient. Async primitives? System.Threading.Tasks.Task. For now, just know that "where does Dictionary<TKey, TValue> come from?" has a clean answer: it comes from the BCL, which ships with .NET.

Three more acronyms show up in interview questions and Microsoft docs. You don't need to memorize their internals, but you should know what each one names.

So the chain goes like this: your C# source compiles to CIL, the CLR's JIT turns CIL into native code, and the CTS/CLS rules underneath make sure types behave consistently. We'll see the source-to-CIL-to-native pipeline up close in the _How C# Works (Compilation & Execution)_ lesson.

When you compile that, the compiler emits CIL instructions for the multiplication, the string interpolation, and the Console.WriteLine call. The CLR's JIT picks those up at runtime and produces real CPU instructions for whatever machine the program is running on.

.NET ships in two flavors, and which one you install depends on what you want to do.

The Runtime is the smaller of the two. It contains the CLR and the BCL, and it can run any compiled .NET application. That's all. No compiler. No CLI tools beyond what's needed to launch a program. You install just the Runtime on production servers where you only need to run apps, not build them.

The SDK is a superset. It contains the Runtime, plus the C# compiler, the dotnet command-line tool, project templates, and everything else you need to write and ship code. If you're developing on your laptop, this is what you install.

The dotnet CLI is the door into the SDK. A few commands you'll use constantly:

You'll meet all of these in the _Setting Up Environment_ and _First C# Program_ lessons. The point here is the conceptual split: SDK = development, Runtime = production.

The BCL covers a lot, but it doesn't cover everything. When you need a third-party library, a logging framework, an ORM, a Markdown parser, you reach for NuGet.

NuGet is the package manager for .NET. Public packages live at nuget.org, and you add one to your project with a single CLI command:

That command edits your project file to record the dependency, downloads the package, and makes its types available via using directives. We'll cover packages in depth in the Namespaces & Assemblies section. For now, the takeaway is that "I need library X" has a one-line answer in .NET, and it's the same answer on every operating system.

When you run dotnet new, the SDK shows you a menu of project templates. Each one is a starting point for a different kind of application. Here are the ones worth knowing about up front:

You don't need to pick one yet. Almost everything in this course works inside a plain console project, and that's what we'll use until later sections introduce web or library scenarios. The reason to glance at the rest now is so the words "Blazor", "MAUI", "ASP.NET Core" aren't mysterious when you run into them.

Pulling everything from this chapter into one table for reference:

If you can read down that table and explain each row in a sentence, you have the conceptual foundation the rest of this course will build on.

Now that you know what's in the .NET ecosystem, the _Setting Up Environment_ lesson installs it. We'll get the SDK on your machine, verify that dotnet --version works, and pick an editor so you're ready to write your first program.