Unit 1: Introducing C# and the .NET Framework [7 Hours]
C# ("C-Sharp") is a modern, object-oriented, and type-safe programming language developed by Microsoft in 2000 as part of its .NET initiative. It belongs to the C family of languages, making its syntax highly familiar to developers who already know C, C++, Java, or JavaScript.
Tested Topics
- CLR & .NET Framework (Managed Code & Architecture) — 2x (2024, 2023)
- Applied Technologies — 1x (2022)
- Memory Management (Garbage Collection) — 1x (2024)
- Platform Independence & Language Interoperability — 1x (2023)
- Type Safety — 1x (2022)
1.1 Object Orientation
Core Definition
Object Orientation (OO) is a programming paradigm that models software as a collection of interacting objects, each combining data (fields/properties) and behaviour (methods), organised around four pillars: encapsulation, inheritance, polymorphism, and abstraction.
Think of OO as writing code the way you think about real things. A "Car" object knows its own speed and knows how to accelerate; you don't reach inside it and move pistons by hand. In C#, this idea is taken all the way down: every type, including built-in ones like int and bool, ultimately derives from a single base class, System.Object. That is why C# is called a purely object-oriented language.
Detailed Explanation
OO exists to solve a maintenance problem. In older procedural code, data and the functions that operate on it are scattered separately, so a single change can ripple unpredictably across the program. OO keeps related data and logic bundled inside one unit (a class), so changes stay local and code becomes reusable. This is delivered through four pillars, each solving a different part of the problem:
Encapsulation hides an object's internal state behind controlled access points. A field is kept private and exposed only through public properties or methods, so external code can never put the object into an invalid state directly.
Inheritance lets a class (the derived class) reuse and extend the members of another class (the base class), written in C# using the colon operator, for example class Car : Vehicle. This avoids rewriting shared behaviour for every related class.
Polymorphism allows the same method call to behave differently depending on the actual object type at runtime. In C# this is achieved through method overriding (using virtual in the base class and override in the derived class) and through method overloading (same method name, different parameter lists).
Abstraction exposes only the essential operations of an object while hiding how those operations are actually implemented, achieved in C# through abstract classes and interfaces.
| Pillar | What it controls | Typical C# tool |
|---|---|---|
| Encapsulation | Who can see or change data | private fields, public get/set |
| Inheritance | Code reuse between related classes | : (colon), base |
| Polymorphism | One call, many behaviours | virtual / override, overload |
| Abstraction | Hiding implementation detail | abstract, interface |
Let's Break It Down
Picture a restaurant kitchen. Encapsulation is the chef hiding the exact recipe inside the kitchen; customers only interact with the menu, never the stove. Inheritance is a "Pizza" recipe reusing a base "Dough" recipe instead of starting from flour every time. Polymorphism is pressing one "Cook" button that fries an egg differently from how it boils pasta, same instruction, different result depending on the dish. Abstraction is the menu itself: it shows "Margherita Pizza," not the twenty steps happening behind the kitchen door.
Common Mistake
Students often assume C# supports multiple inheritance of classes, like some other languages. It does not: a C# class can inherit from only one base class, but it can implement any number of interfaces, which is how C# achieves a similar effect safely.
Test Yourself
- Which pillar would you use to stop external code from directly setting a bank account's balance field, and how would you apply it?
- A Dog class and a Cat class both override a method called MakeSound() inherited from a shared Animal base class. Which pillar is this demonstrating?
Answers: 1) Encapsulation, by making the field private and only allowing changes through a controlled method such as Deposit() or Withdraw().
2) Polymorphism, since the same method call produces different behaviour depending on the actual object type.
Summary
- OO models software as objects that bundle data and behaviour together.
- C# is purely object-oriented: every type ultimately derives from System.Object.
- The four pillars are encapsulation, inheritance, polymorphism, and abstraction.
- C# allows single class inheritance only, but multiple interface implementation.
One-Liner Revision
Object orientation bundles data and behaviour into objects, built on encapsulation, inheritance, polymorphism, and abstraction.
1.2 Type Safety
Core Definition
Type safety is a property of a programming language where the compiler and the runtime enforce that an object of one type cannot be treated as, or silently converted into, an incompatible type without an explicit, verified conversion.
In a type-safe language like C#, you cannot accidentally treat a piece of text as a number, or sneak past the rules and read memory in a format it was never meant to be read in. The compiler checks first, and where the compiler cannot be sure, the runtime checks again while the program is executing.
Detailed Explanation
Type safety operates in two layers. Compile-time checking catches obvious mismatches before the program ever runs, such as assigning a string value to an int variable; the code simply fails to compile. Runtime checking covers cases the compiler cannot fully verify in advance, such as casting an object reference to a more specific type; here the CLR checks the object's real identity at the moment of the cast and throws an InvalidCastException if it does not match, rather than allowing the program to misread memory.
This matters because it eliminates an entire class of bugs and security holes that are common in languages without these guarantees, such as buffer overflows and pointer mismatches in C/C++, at the cost of a small amount of runtime overhead for the checks. C# does allow developers to deliberately step outside these guarantees using an unsafe code block with raw pointers, typically for performance-critical code or interoperating with native libraries, but this is an explicit opt-out, not the default behaviour.
| Aspect | Type-safe (C#) | Not fully type-safe (C/C++) |
|---|---|---|
| Invalid cast | Throws InvalidCastException | Undefined behaviour [verify] |
| Array access | Bounds checked, throws IndexOutOfRangeException | Not checked, can overrun memory |
| Memory access | Mediated by the CLR | Direct raw pointer access |
Common Mistake
Students assume "type safe" means the program cannot have bugs. It actually means invalid type operations are caught and reported explicitly, usually as an exception, instead of silently corrupting memory or producing garbage results.
Test Yourself
- What happens in C# if you try to cast an object that is actually a Dog into a Cat at runtime?
- Why is type safety generally considered more secure than raw pointer-based memory access?
Answers: 1) The CLR detects the mismatch and throws an InvalidCastException instead of allowing the cast.
2) Because every access is checked against the object's real type and bounds, preventing the program from reading or writing memory it should not be able to reach.
Summary
- Type safety prevents one type from being misread or miscast as another.
- Checking happens at compile time and again at runtime where needed.
- Invalid operations throw exceptions instead of corrupting memory.
- C# allows opting out via unsafe code for special, deliberate cases.
One-Liner Revision
Type safety means invalid type conversions are caught by the compiler or CLR and reported as errors, not silently allowed.
1.3 Memory Management
Core Definition
Memory management in .NET is the automatic process by which the CLR allocates memory for objects on the managed heap and reclaims memory occupied by objects that are no longer reachable, carried out by a component called the Garbage Collector (GC).
In a language like C, you must explicitly request memory and then explicitly free it, and forgetting the second step causes a memory leak. In C#, the CLR's garbage collector continuously watches which objects are still actually in use and automatically clears out the ones that are not, without the developer writing any cleanup code for most objects.
Detailed Explanation
Two storage areas are involved. The stack holds value types, local variables, and method call frames; it is fast, follows a strict last-in-first-out order, and is automatically cleared the moment a method returns. The managed heap holds reference type objects created with new, and these are only cleared once nothing in the program can reach them any more.
The GC uses a generational strategy, based on the observation that most objects die young while a small number live for a long time:
Step 1 → A newly created object is placed in Generation 0 of the heap.
Step 2 → When Generation 0 fills up, a collection runs: the GC marks every object still reachable from a root reference, such as a local variable or static field.
Step 3 → Unreachable objects are reclaimed; the surviving reachable objects are compacted and promoted into Generation 1.
Step 4 → Objects that keep surviving repeated collections eventually move into Generation 2, which holds long-lived objects and is collected far less often, since scanning it is the most expensive.
Step 5 → Very large objects, generally 85,000 bytes or more, are placed in a separate Large Object Heap (LOH), which is collected less frequently because compacting large blocks is costly. [verify exact threshold]
This generational design exists because checking a small, frequently-changing Generation 0 is far cheaper than rescanning the entire heap on every collection, while long-lived Generation 2 objects are mostly left alone.
Not everything the GC manages is memory. Unmanaged resources such as file handles, database connections, and network sockets are not tracked by the GC at all, so classes holding them implement IDisposable.Dispose() for immediate, deterministic cleanup, commonly invoked through a using statement. A Finalize method (written as a destructor, ~ClassName()) exists as a backup safety net the GC calls at an unpredictable time, and should never be relied on for timely cleanup.
Memory Hook
Gen 0 is the nursery, checked constantly. Gen 1 is the teenager, checked occasionally. Gen 2 is the veteran, rarely disturbed. The longer an object survives, the less often the GC bothers checking on it.
Let's Break It Down
Imagine a shared office. Your personal desk drawer is the stack: when you leave for the day, it is automatically cleared out, no janitor needed. The shared storage room down the hall is the heap: items pile up there as people add things, and a janitor (the GC) periodically walks through, checking what is still claimed by someone and clearing out everything that has been abandoned.
Common Mistake
Calling GC.Collect() manually is often assumed to be good practice for "cleaning up." In reality it forces an expensive, full collection outside the GC's own optimized schedule, and is discouraged except in narrow diagnostic scenarios. Students also frequently confuse Dispose, which you call yourself for immediate cleanup, with Finalize, which only the GC calls, at an unknown time.
Test Yourself
- Why are newly created objects placed in Generation 0 instead of directly in Generation 2?
- What is the practical difference between calling Dispose() yourself and relying on the finalizer to release a database connection?
Answers: 1) Most objects are short-lived, so checking the small, fast Generation 0 frequently is far cheaper than scanning the whole heap; only survivors earn promotion to higher generations.
2) Dispose() releases the unmanaged resource immediately and predictably, while the finalizer runs at an unknown future time chosen by the GC, which can leave the connection open far longer than necessary.
Summary
- Value types and call frames live on the stack; reference objects live on the managed heap.
- The GC reclaims heap memory automatically using a generational scheme: Gen 0, Gen 1, Gen 2, plus the LOH for large objects.
- Generations exist because most objects are short-lived, so frequent small checks are cheaper than full scans.
- Unmanaged resources need explicit Dispose(), since the GC does not track them.
One-Liner Revision
The GC automatically reclaims heap memory using generations 0, 1, and 2, while Dispose() handles unmanaged resources the GC cannot see.
1.4 Platform Support
Core Definition
Platform support describes which operating systems and device types a .NET application can run on, a capability that has expanded considerably across the framework's history, moving from a Windows-only runtime to a fully cross-platform one.
Originally, a C# program built for the classic .NET Framework would only run on Windows, no exceptions. Today's .NET runs the same kind of C# code on Windows, Linux, and macOS, and reaches mobile platforms too.
Detailed Explanation
Classic .NET Framework (1.0 onward) was tightly coupled to Windows, bundling Windows-specific technologies like WPF and WinForms, and was never officially cross-platform.
Mono, an independently developed open-source implementation of the CLR, made it possible to run C# and .NET code on Linux, macOS, and mobile devices long before Microsoft's own runtime supported any of that, and later became the engine underneath Xamarin.
.NET Core was Microsoft's own rebuild of the runtime, designed from the ground up to be cross-platform across Windows, Linux, and macOS, open source, and modular, so applications could pick only the pieces they need.
The unified .NET (.NET 5 and later) merged .NET Framework, .NET Core, and the ideas behind Xamarin into a single runtime and a single set of APIs, governed by .NET Standard (covered in 1.9), so developers no longer have to choose between "Framework" and "Core" versions.
| Implementation | Primary platform(s) | Status |
|---|---|---|
| .NET Framework | Windows only | Legacy, maintenance only |
| Mono | Linux, macOS, mobile | Lives on inside Xamarin |
| .NET Core | Windows, Linux, macOS | Merged into unified .NET |
| .NET (5+) | Windows, Linux, macOS, mobile, cloud | Current, actively developed |
Common Mistake
Students often think ".NET Core" still exists today as a separate, current product. Current versions are simply called ".NET" (.NET 6, .NET 7, .NET 8, and onward); the "Core" name was retired once .NET Framework and .NET Core merged into one platform. [verify exact version where naming changed]
Test Yourself
- Why could Mono run C# applications on Linux years before Microsoft's own .NET Framework could?
- What exactly was unified when Microsoft released ".NET 5"?
Answers: 1) Mono was an independent, open-source reimplementation of the CLR built specifically to support non-Windows platforms, while .NET Framework was designed only for Windows.
2) .NET Framework, .NET Core, and the Xamarin/Mono lineage were brought together into one runtime and one API surface, removing the need to choose between them.
Summary
- Classic .NET Framework was Windows-only.
- Mono brought C# to Linux, macOS, and mobile well before Microsoft's own cross-platform effort.
- .NET Core was Microsoft's official cross-platform rebuild.
- .NET 5 and later unified everything into one runtime and API surface.
One-Liner Revision
Platform support evolved from Windows-only .NET Framework, through Mono and .NET Core, into a single unified cross-platform .NET.
1.5 C# and CLR
Core Definition
The relationship between C# and the CLR is one of source language to execution engine: C# source code is never executed directly by the operating system; it is first compiled into a platform-independent intermediate form and then executed by the Common Language Runtime (CLR), which translates it into native machine instructions while the program runs.
Writing C# is like writing a recipe in a universal cooking shorthand. The CLR is the kitchen that reads that shorthand and actually turns it into a finished dish, on whatever stove, meaning CPU, it happens to be standing in front of.
Detailed Explanation
The full pipeline from source code to running program follows a fixed sequence:
Step 1 → Source code is written as .cs files in C#.
Step 2 → The C# compiler (csc, or the modern Roslyn compiler) compiles this source not into machine code, but into Common Intermediate Language (CIL/MSIL), a CPU-independent bytecode.
Step 3 → The compiler packages this IL together with metadata describing types, versions, and references into an assembly, a .dll or .exe file.
Step 4 → When the assembly is run, the CLR's Class Loader loads the required types into memory.
Step 5 → The Just-In-Time (JIT) compiler converts the IL into native machine code for the exact CPU and operating system it is running on, compiling each method just before it is first executed rather than translating the whole assembly upfront.
Step 6 → The CLR executes the resulting native code, simultaneously providing services such as garbage collection, type checking, and exception handling throughout execution.
This two-step compilation model exists for two reasons. First, the same compiled assembly can run unchanged on any CPU and operating system combination that has a compatible CLR, giving true "compile once, run anywhere" portability. Second, the JIT can optimize the native code specifically for the exact machine it is running on at that moment, something a single ahead-of-time compile to one fixed CPU target cannot do as precisely.
Let's Break It Down
The C# compiler is like a writer producing a manuscript in a universal shorthand, the IL. The CLR is a live interpreter standing on stage, translating that shorthand into the local language, machine code, for whichever audience, the CPU, happens to be sitting in front of it, line by line as it is needed, rather than translating the entire book in advance.
Common Mistake
Many students assume the C# compiler directly produces machine code. It does not; it stops at IL. Turning IL into native code is the JIT compiler's job, and that happens at run time, not at compile time.
Test Yourself
- Arrange in the correct order: JIT compilation, writing C# source code, csc compiling to IL, CLR loading the assembly.
- Why does compiling to IL instead of directly to machine code make .NET applications portable across different CPUs?
Answers: 1) Writing C# source code → csc compiling to IL → CLR loading the assembly → JIT compilation.
2) IL is CPU-independent, so the same assembly can be JIT-compiled into the correct native instructions on whichever CPU it actually runs on, instead of being locked to one CPU at compile time.
Summary
- C# source compiles to IL, not directly to machine code.
- IL plus metadata is packaged into an assembly (.dll/.exe).
- The CLR loads the assembly and the JIT compiles IL to native code at run time, method by method.
- This two-step model enables portability and machine-specific optimization.
One-Liner Revision
C# compiles to IL, and the CLR's JIT compiler turns that IL into native code at run time, on the exact machine it is running on.
1.6 CLR and .NET Framework
Core Definition
The Common Language Runtime (CLR) is the managed execution engine sitting at the core of the .NET Framework, responsible for loading and running compiled .NET assemblies, while the .NET Framework as a whole is the larger platform that bundles the CLR together with a vast class library and supporting language specifications.
If the .NET Framework is the whole toolbox, the CLR is the actual engine inside it that makes code run; everything else in the box, libraries and tools, is built around that engine or depends on it.
Detailed Explanation
The CLR is made up of several components, each handling a distinct responsibility:
The Class Loader locates and loads compiled types from assemblies into memory only when they are first needed. The JIT Compiler converts IL into native code at run time, as described in 1.5. The Garbage Collector automatically reclaims unused heap memory, as described in 1.3. The Exception Manager provides structured, language-independent exception handling, so a try/catch block behaves identically regardless of whether the calling code was originally written in C# or another .NET language.
Two further pieces make cross-language interoperability possible. The Common Type System (CTS) defines one single set of data types that every .NET language must map onto, so an int in C# and an equivalent integer type in another .NET language are the exact same underlying type at runtime. The Common Language Specification (CLS) is a smaller subset of CTS rules that, if followed, guarantees a library written in one .NET language can be safely consumed from any other .NET language.
| Component | Role |
|---|---|
| Class Loader | Loads compiled types into memory |
| JIT Compiler | Converts IL into native code |
| Garbage Collector | Reclaims unused heap memory |
| CTS | Shared type system across all .NET languages |
| CLS | Ruleset guaranteeing cross-language compatibility |
Test Yourself
- Why can a class written in C# call a method written in another .NET language without any extra conversion code?
- Which CLR components are mainly about performance, and which are mainly about safety or compatibility?
Answers: 1) Because both languages compile down to the same Common Type System, so their data types are identical at the CLR level.
2) The JIT Compiler is mainly about performance; the Garbage Collector handles automatic memory safety; CTS and CLS handle cross-language compatibility.
Summary
- The CLR is the execution engine at the core of the .NET Framework.
- Its components include the Class Loader, JIT Compiler, Garbage Collector, and Exception Manager.
- CTS provides one shared type system; CLS guarantees safe cross-language library use.
One-Liner Revision
The CLR is the .NET Framework's execution engine, made up of the Class Loader, JIT Compiler, Garbage Collector, and the CTS/CLS rules that enable cross-language interoperability.
1.7 Other Frameworks
Core Definition
Besides the standard .NET Framework, several alternative or specialized .NET-compatible frameworks exist, each implementing the CLR/CTS specification for a particular need such as cross-platform support, mobile development, or game engines.
Not every team needs Microsoft's original Windows-only .NET Framework. Some needed Linux support, some needed mobile apps, some needed games, so other runtimes grew up around the same underlying language and rules to serve those needs.
Detailed Explanation
Mono is an open-source CLR implementation that enabled C# on Linux and macOS, and historically powered mobile development before Microsoft's own cross-platform runtime existed.
Xamarin is built on top of Mono and lets developers write native iOS and Android apps in C# from a largely shared codebase, rather than maintaining separate native projects per platform.
Unity, a widely used game engine, uses a Mono-based runtime to let C# scripts drive game logic across many target platforms, from PC to console to mobile, from a single codebase. [verify current Unity runtime details]
| Framework | Built on | Main use case |
|---|---|---|
| Mono | Independent CLR implementation | Linux/macOS, legacy mobile |
| Xamarin | Mono | Native mobile apps in C# |
| Unity | Mono-based runtime | Game development |
Test Yourself
- What underlying runtime made Xamarin's "write C# for mobile apps" approach possible before Microsoft's own .NET Core existed?
- Why might a game studio prefer Unity's C# runtime over building a plain console application directly on .NET?
Answers: 1) Mono, the independent open-source CLR implementation that Xamarin is built on top of.
2) Unity provides a game-focused engine and rendering pipeline around the C# runtime, which a plain .NET console application does not include.
Summary
- Mono brought C# to non-Windows platforms before Microsoft's own runtime did.
- Xamarin, built on Mono, targets native mobile development.
- Unity uses a Mono-based runtime to power cross-platform game development in C#.
One-Liner Revision
Mono, Xamarin, and Unity are alternative .NET-compatible runtimes built to serve cross-platform, mobile, and game development needs respectively.
1.8 Framework Overview
Core Definition
The .NET Framework architecture is a layered system: the operating system sits at the bottom, the CLR sits above it managing execution, a large standard library called the Framework Class Library (FCL) sits above the CLR providing reusable functionality, and application-facing technologies such as ASP.NET, WPF, and ADO.NET sit on top, used directly by developer code.
Picture it as a layer cake. The bottom layer is Windows itself. On top of that sits the CLR, actually running the code. On top of that sits a huge pre-written library, so developers do not reinvent file handling or string operations. On top of all of that sit ready-made technologies for building a specific kind of application, web, desktop, or service.
Detailed Explanation
Layer 1 (bottom) → The Operating System provides raw resources, memory, threads, and I/O, that the CLR runs on top of.
Layer 2 → The CLR manages execution, memory, and type safety, as detailed in 1.6.
Layer 3 → The Framework Class Library (FCL), sometimes called the Base Class Library (BCL) for its core subset, provides thousands of pre-built classes for collections, file I/O, networking, and string manipulation, shared by every .NET language.
Layer 4 (top) → Application technologies built on the FCL, including ASP.NET for web applications, ADO.NET for database access, and WPF/WinForms for desktop UI, each covered individually in 1.10.
Cutting across every layer → The Common Type System (CTS) and Common Language Specification (CLS) ensure C#, VB.NET, and other .NET languages interoperate seamlessly within the same application.
| Layer | Example | Purpose |
|---|---|---|
| Operating System | Windows | Hardware and resource access |
| CLR | Execution engine | Runs IL, manages memory and types |
| FCL / BCL | System.Collections, System.IO | Reusable building blocks |
| Application technologies | ASP.NET, WPF, ADO.NET | Build specific kinds of applications |
Common Mistake
Students often treat the FCL/BCL as if it were the same thing as the CLR. The CLR is the engine that runs code; the FCL/BCL is a library of pre-written code that the CLR happens to run. They sit at different layers of the architecture.
Test Yourself
- Where does ADO.NET sit in the layered architecture relative to the CLR?
- What is the practical benefit of every .NET language sharing the same FCL?
Answers: 1) ADO.NET is an application technology in the top layer, built on top of the FCL, which itself sits above the CLR.
2) Developers in any .NET language get access to the same tested, reusable functionality, instead of each language maintaining its own separate library.
Summary
- The architecture layers from bottom to top: OS, CLR, FCL/BCL, application technologies.
- CTS and CLS cut across all layers to enable cross-language interoperability.
- The FCL is a shared library, distinct from the CLR that executes code.
One-Liner Revision
The .NET Framework layers the OS, the CLR, the shared FCL, and application-specific technologies on top of one another.
1.9 .NET Standard 2.0
Core Definition
.NET Standard is a formal specification, a fixed set of APIs, that any .NET implementation (.NET Framework, .NET Core, Mono/Xamarin) can choose to implement, so that a class library built against a given .NET Standard version is guaranteed to run on every implementation that supports it. .NET Standard 2.0 is a specific, widely adopted version of that specification, notable for substantially expanding API coverage and adding compatibility with existing .NET Framework libraries.
Before .NET Standard, writing a library that worked on both .NET Framework and the newer .NET Core meant guessing which APIs were safe to use on both. .NET Standard is essentially a published checklist; if a library only uses APIs on that checklist, it is guaranteed to run anywhere supporting that checklist version.
Detailed Explanation
The problem .NET Standard solves: before it existed, an earlier approach called Portable Class Libraries (PCL) tried to support sharing code across platforms but was limited and confusing to configure. .NET Standard replaced that approach with a single, versioned, growing API surface that every implementation could target consistently.
Versioning works as a trade-off: a higher .NET Standard version number means more APIs are available to use, but fewer, newer runtimes support it; a lower version means fewer APIs but support from a wider range of runtimes, including older ones. A library targeting .NET Standard 1.0 runs almost everywhere; a library targeting .NET Standard 2.0 requires a runtime new enough to implement that later version.
.NET Standard 2.0 specifically mattered because it roughly tripled the API surface compared to earlier 1.x versions, and introduced a compatibility shim that let .NET Standard 2.0 libraries directly reference many existing .NET Framework class libraries. [verify exact API count figures] This made migrating large existing Windows codebases toward cross-platform .NET realistic for the first time, rather than requiring a full rewrite.
With the unified .NET (5 and later) model, Microsoft generally recommends targeting .NET Standard mainly when a library still needs to support older .NET Framework consumers; new code without that backward-compatibility requirement can target modern .NET directly. [verify current guidance]
| Concept | .NET Standard | Unified .NET |
|---|---|---|
| Purpose | Common API contract for libraries | Not needed; one runtime model |
| Targets | Multiple implementations (Framework, Core, Mono) | One unified runtime |
| Version meaning | Higher = more APIs, narrower runtime support | Version = yearly feature release (.NET 6, 7, 8...) |
Common Mistake
Students frequently confuse .NET Standard with .NET Core. .NET Standard is only a specification, a rulebook with no executable runtime of its own, while .NET Core is an actual runtime/implementation that follows that rulebook.
Test Yourself
- Why would a library deliberately target .NET Standard 1.x instead of 2.0, even though 2.0 offers more APIs?
- What made .NET Standard 2.0 particularly significant for teams with existing .NET Framework code?
Answers: 1) Targeting a lower version reaches a wider range of runtimes, including older ones that cannot implement 2.0.
2) Its expanded API surface and compatibility shim allowed it to reference existing .NET Framework libraries directly, easing migration without a full rewrite.
Summary
- .NET Standard is a specification, not a runtime, that guarantees API consistency across implementations.
- Higher version numbers mean more APIs but narrower runtime support.
- .NET Standard 2.0 expanded the API surface and enabled referencing existing .NET Framework libraries.
One-Liner Revision
.NET Standard is a versioned API contract that guarantees a library runs across every implementation supporting that version, and 2.0 made cross-compatibility with .NET Framework practical.
1.10 Applied Technologies
Core Definition
Applied technologies refers to the specialized frameworks built on top of the CLR and FCL that each target a specific category of application, web, desktop, data access, or distributed services, so a developer reaches for the matching technology rather than working with the bare class library directly.
Once the language and core libraries are known, a developer does not build a website or a database connection from scratch; they reach for the matching ready-built technology for that job, the same language underneath, a different toolkit on top depending on what is being built.
Detailed Explanation
ASP.NET (and its modern successor ASP.NET Core) is the framework for building web applications and web APIs, handling HTTP requests, routing, and page or response rendering.
ADO.NET provides classes for connecting to and querying databases, including connections, commands, and data readers, forming the data-access layer that higher-level tools are built on top of.
Windows Forms (WinForms) is an early, event-driven framework for building traditional desktop GUI applications on Windows.
WPF (Windows Presentation Foundation) is a more modern desktop UI framework using XAML markup, offering richer, vector-based, data-bound interfaces compared to WinForms.
WCF (Windows Communication Foundation) is a framework for building distributed, service-oriented applications that communicate over multiple protocols such as HTTP and TCP, though it has largely been superseded in new projects by lightweight Web APIs and gRPC. [verify current adoption status]
Entity Framework is an Object-Relational Mapper (ORM) built above ADO.NET that lets developers query and update a database using ordinary C# objects instead of writing raw SQL by hand.
| Technology | Application type | Built on |
|---|---|---|
| ASP.NET | Web apps / APIs | FCL, CLR |
| ADO.NET | Database access | FCL |
| WinForms | Desktop GUI (classic) | FCL |
| WPF | Desktop GUI (modern) | FCL |
| WCF | Distributed services | FCL |
| Entity Framework | ORM / data access | ADO.NET |
Test Yourself
- If a project needs a modern, richly data-bound desktop interface rather than a basic one, would WinForms or WPF fit better, and why?
- What role does Entity Framework play relative to ADO.NET?
Answers: 1) WPF, since it offers vector-based, richly data-bound interfaces through XAML, which WinForms was not designed for.
2) Entity Framework sits on top of ADO.NET as an ORM, letting developers work with C# objects instead of writing raw SQL, while ADO.NET still does the actual database communication underneath.
Summary
- ASP.NET targets web apps/APIs; ADO.NET targets database access.
- WinForms and WPF target desktop GUIs, classic and modern respectively.
- WCF targets distributed services; Entity Framework is an ORM built above ADO.NET.
One-Liner Revision
Applied technologies like ASP.NET, ADO.NET, WPF, WinForms, WCF, and Entity Framework each specialize the FCL for a specific kind of application.
Whole Chapter Summary
Whole Chapter Summary
- Object Orientation: C# models software as objects built on encapsulation, inheritance, polymorphism, and abstraction.
- Type Safety: the compiler and CLR enforce that types cannot be misused or miscast without an explicit, checked conversion.
- Memory Management: the GC automatically reclaims heap memory using a generational scheme, while Dispose() handles unmanaged resources.
- Platform Support: .NET moved from Windows-only, through Mono and .NET Core, to a single unified cross-platform runtime.
- C# and CLR: C# compiles to IL, which the CLR's JIT compiler turns into native code at run time on the exact machine running it.
- CLR and .NET Framework: the CLR is the execution engine inside the .NET Framework, with CTS and CLS enabling cross-language interoperability.
- Other Frameworks: Mono, Xamarin, and Unity extend C#/.NET into non-Windows, mobile, and game development contexts.
- Framework Overview: the architecture layers the OS, CLR, FCL, and application technologies on top of one another.
- .NET Standard 2.0: a versioned API contract guaranteeing library compatibility across implementations, with 2.0 enabling practical .NET Framework interoperability.
- Applied Technologies: ASP.NET, ADO.NET, WPF, WinForms, WCF, and Entity Framework each specialize the platform for a specific application type.
Key Points Sheet
| Point / Sequence | Meaning |
|---|---|
| C# → IL → Assembly → Class Loader → JIT → Native code | Full compilation and execution pipeline from source to running program |
| Gen 0 → Gen 1 → Gen 2 → LOH | Generational garbage collection order, from frequently checked to rarely checked |
| CTS | Single shared type system across all .NET languages |
| CLS | Ruleset guaranteeing safe cross-language library consumption |
| OS → CLR → FCL/BCL → Application technologies | Layered .NET Framework architecture, bottom to top |
| .NET Standard version | Higher version = more APIs, narrower runtime support |
Exam Questions
- What is the importance of Garbage collection in .NET framework? Explain .NET Framework architecture with suitable diagram. (2024)
- What is managed code? Give reason to justify the statement "DOT NET framework is platform independent and Language interoperability". (2023)
- What do you mean by "safe" programming language? Explain any four applied technologies in DotNet framework. (2022)
Last-Minute Revision Sheet
Last-Minute Revision Sheet
Object Orientation → encapsulation, inheritance, polymorphism, abstraction.
Type Safety → compiler + CLR block invalid type use, throw exceptions instead.
Memory Management → GC, Gen 0/1/2 + LOH, Dispose for unmanaged resources.
Platform Support → Framework (Windows only) → Mono/Core (cross-platform) → unified .NET.
C# and CLR → C# → IL → assembly → JIT → native code, at run time.
CLR and .NET Framework → Class Loader, JIT, GC, Exception Manager, CTS, CLS.
Other Frameworks → Mono (cross-platform), Xamarin (mobile), Unity (games).
Framework Overview → OS → CLR → FCL/BCL → app technologies layered.
.NET Standard 2.0 → shared API checklist, big jump in coverage, Framework-compatible.
Applied Technologies → ASP.NET (web), ADO.NET (data), WinForms/WPF (desktop), WCF (services), EF (ORM).