DEV Community: sadık emre

The Heart of .NET: A Deep Dive into the System Namespace

sadık emre — Fri, 14 Aug 2026 02:00:55 +0000

If you write C# every day, you use the System namespace all the time — probably without thinking about it. In this post, we'll slow down and really look at it: what it is, what's inside it, where it stops, how it got here, and where it's going next.

I'll keep the words simple, but I won't skip the details.

A quick but important note: "System" is not a class

Let's clear up a common mix-up first.

System is not a single class. It's a namespace — a logical group that holds many classes, structs, interfaces, and delegates. Types like System.String, System.Console, and System.DateTime live inside this namespace.

This matters because System is not one file or one DLL either. There's a whole architecture behind it, and we'll get to that soon.

How long has System been around?

2002 — System was born with .NET Framework 1.0. It has been the backbone of every .NET version since then.
It was designed together with the CLR (Common Language Runtime), the engine that runs your code. System became the "base library" built on top of that engine.

That's over 20 years of active use and active development. In software terms, that's a long life — and System is far from outdated. It gets updated every single year.

So how is this huge, decades-old thing organized on the inside? That's where "namespace levels" come in.

Namespace levels: what does "level" actually mean?

A namespace is a purely logical grouping, separated by dots (.). It's not a real folder on your disk — it's just a way to organize code.

Level	What it means	Examples
Root level	No dots at all, sits at the very top	`System`
Level 1	Contains one dot	`System.Collections`, `System.Linq`, `System.IO`, `System.Threading`, `System.Text`, `System.Net`, `System.Reflection`, `System.Diagnostics`, `System.Security`, `System.Numerics`, `System.Globalization`
Level 2	Contains two dots	`System.Collections.Generic`, `System.Threading.Tasks`, `System.Text.Json`, `System.Security.Cryptography`, `System.Net.Http`, `System.Text.RegularExpressions`
Level 3 and beyond	Three or more dots	`System.Runtime.CompilerServices`, `System.Diagnostics.CodeAnalysis`, `System.Threading.Tasks.Dataflow`, `System.Collections.ObjectModel`

Why is it split up like this?

Logical grouping — related types stay together. All collection types live under Collections, all networking types live under Net.
Avoiding name clashes — two namespaces can have a type with the same name. For example, both System.Threading.Timer and System.Timers.Timer exist. Without namespaces, these would collide.
Pick only what you need — you bring in one namespace with using, without pulling in everything else.

Levels don't automatically include each other

Writing using System.Collections.Generic; does not automatically add System. And writing using System; does not give you the Where or Select methods from System.Linq. Each level is its own independent unit — you need using for each one, wherever you use it.

Also, the namespace hierarchy and the physical assembly (DLL) structure don't line up perfectly. System.Linq sits logically under System, but it can live in its own DLL (System.Linq.dll). A namespace is about "folders" of logic; an assembly is about "which file." These are two different things.

Now that we've seen how namespaces are organized, let's look at how the things inside them differ from each other.

Class, struct, interface, delegate, method: who does what?

Before we get into tables, let's make these five terms clear. They're all "types," but they play very different roles.

Term	What it means	Example
Class	A reference type. Holds data (fields/properties) and behavior (methods) together, and supports inheritance	`Console`, `StringBuilder`, `Exception`
Struct	A value type. Usually small, lightweight, and often immutable (can't be changed)	`DateTime`, `Guid`, `TimeSpan`
Interface	Not an actual implementation — it's a contract. It says which methods/properties must exist	`IDisposable`, `IComparable<T>`
Delegate	A type-safe "pointer to a function" — lets you pass a method around like a value	`Action<T>`, `Func<T,TResult>`
Method	A block of code defined inside a class or struct that does one job	`String.ToUpper()`, `Console.WriteLine()`

A class defines "what something is." A method defines "what it can do." An interface doesn't do anything by itself — it just says "you need to do this." The actual work is done by the classes that implement it.

The real System classes hiding behind C# keywords

Here's something interesting: keywords like class, struct, enum, and delegate in C# are actually syntactic sugar — shortcuts the compiler links to real classes in the System namespace behind the scenes.

C# keyword	The real base class behind it
`class` (when you don't specify a base class)	`System.Object`
`struct`	`System.ValueType`
`enum`	`System.Enum`
`delegate`	`System.MulticastDelegate` (which itself comes from `System.Delegate`)

So when you write enum Color { Red, Blue }, the compiler treats it as a type that inherits from System.Enum behind the scenes. This also explains why enums have methods like .ToString() and .HasFlag() — they all come from System.Enum.

Boxing and unboxing: how value types become System.Object

Since System.Object is the ancestor of every type, something interesting happens when you want to treat a value type (like int) as an object:

Boxing — the value type's data gets wrapped in a "box" on the heap and turned into a reference type: object box = 5;
Unboxing — that boxed value gets converted back to its original value type: int number = (int)box;

This looks small, but it has a real performance cost (extra heap allocation, type checks). It's also one reason generic collections (like List<int>) are faster than old, non-generic collections (like ArrayList, which is object-based): generic collections don't need boxing or unboxing.

Static classes: why you don't "new" up a Console

You've probably noticed you never write new Console() when calling Console.WriteLine(). That's because classes like Console, Math, Convert, and Environment are defined as static classes.

A static class:

Can't be instantiated — you can't create an object from it with new.
All its members (methods, properties) are called directly through the class name.
Usually holds no state — it just offers behavior or helper functions.

This design makes sense: there's no need for "multiple instances" of the console or of math operations. One console, one math library, is enough for the whole system.

Now that the basic concepts are clear, let's take a step back and ask: where do all these classes, structs, and interfaces actually live?

Behind the scenes: how is System actually packaged?

Most people picture System as "one big DLL." That's not how it really works — but before we get there, let's clear up a few acronyms you'll keep running into, because they all describe different layers of this same packaging story:

Acronym	Full name	What it means
CLR	Common Language Runtime	The engine that runs your code — memory management, JIT compiling, and garbage collection all happen here
CTS	Common Type System	The shared type rules that all .NET languages (C#, F#, VB.NET) agree on
CLS	Common Language Specification	The minimum set of rules different .NET languages must follow so their code can work together
BCL	Base Class Library	The most fundamental library on top of the CLR; most of the System namespace lives here
FCL	Framework Class Library	BCL plus the wider libraries built on top of it (in the old .NET Framework days, this was the umbrella term covering everything, including ASP.NET and WinForms)

In short: the CLR runs your code, CTS/CLS set the type rules, and BCL/FCL are the ready-made libraries built on top of those rules. System is the core of the BCL. So where does the BCL actually live, physically? That's where the real assembly architecture comes in:

mscorlib.dll — the historic assembly that held most of the System types back in the .NET Framework days.
System.Private.CoreLib.dll — the internal assembly that replaced mscorlib after .NET Core, holding the real implementation of these types. The word "Private" isn't there by accident — this assembly isn't meant to be referenced directly. It's an internal, runtime-specific piece.
Reference assemblies like System.Runtime.dll — the contract files you see at compile time, which get filled in with the real implementation at runtime.

So System looks like one solid block to a developer, but behind the scenes it's built as a modular package. This lets pieces get updated independently, get distributed through NuGet, and get trimmed away when an app doesn't need them.

This architecture didn't appear overnight — let's take a quick trip through time to see how we got here.

The evolution story: from Windows-only to everywhere

Era 1 — .NET Framework (roughly 2002–2019): Windows-only, one big monolithic piece.

Era 2 — .NET Core (from 2016): Open source, cross-platform (Windows/Linux/macOS), modular. System got split into small NuGet packages.

Era 3 — .NET 5 and beyond (2020+): Framework and Core merged into one. A single, consistent platform with a yearly release.

A quick side note — .NET Standard: Between these eras, there was a bridge concept called .NET Standard. It defined which common System APIs different .NET flavors (Framework, Core, Xamarin, etc.) all supported. Once .NET 5 merged the platforms, the need for this bridge mostly went away — but you'll still see targets like netstandard2.0 in older libraries.

The philosophy shifted too: System used to be "one giant library that includes everything." Today it's "a lean, performance-first core that shrinks when it needs to." One of the clearest results of this shift is how much attention performance gets now.

Specializing for performance

Span<T> / Memory<T> — work with memory without copying it, cutting down on allocations by a lot.
Generic math (interfaces like INumber<T>) — write type-safe, reusable math code that works across different numeric types.
SIMD support — use the CPU's vector units (like AVX or ARM SVE) directly.
Native AOT — compile straight to machine code with no runtime needed, shrinking startup time and memory footprint.
ArrayPool (in System.Buffers) — a memory pool for arrays you use often, so you reuse memory instead of allocating a new array every time.

These performance goals show up most clearly in the current release.

Where things stand today: .NET 10 and System

.NET 10 shipped in November 2025 as an LTS (Long-Term Support) release, supported until 2028. Highlights include:

New APIs across cryptography, diagnostics, numerics, globalization, and serialization.
AI moved to the center of the platform with the Microsoft Agent Framework, letting you build AI agents directly into .NET apps.
JIT compiler improvements for structs, loops, and array handling.
Pieces like System.Linq.AsyncEnumerable becoming part of the core libraries.

What's happening right now: .NET 11 in preview

System is still being actively developed — right now, as you're reading this. .NET 11 is set to ship in November 2026, and preview releases are coming out one after another.

Runtime Async — async code redesigned at the runtime level, aiming for cleaner stack traces and less overhead.
CoreCLR running on WebAssembly — deeper integration between .NET and browser/WASM environments.
Built-in Zstandard compression support.
BFloat16 and other numeric types built for AI workloads.
Updated hardware requirements.

Where is System heading?

Cloud-first design — containers, microservices, fast startup times.
AI built in — AI agents embedded directly into the platform.
Performance close to the hardware — SIMD, generic math, Native AOT.
Staying modular and small — only the pieces you need get shipped.
Expanding across platforms — WebAssembly, mobile, embedded systems.

But this growth isn't unlimited. System is deliberately kept small — which is exactly why it's worth looking closely at where its limits are.

Where System falls short — and who fills the gap

This is probably the clearest proof that System is not trying to be "a library that does everything." It's intentionally kept limited.

Need	What System offers	Who fills the gap
Dependency Injection	Nothing built in	`Microsoft.Extensions.DependencyInjection`
Structured logging	Only basic `Debug`/`Trace`	`Microsoft.Extensions.Logging`, Serilog, NLog
App configuration	Nothing built in	`Microsoft.Extensions.Configuration`
Web/API framework	Nothing but `HttpClient`	ASP.NET Core (`Microsoft.AspNetCore.*`)
ORM / database access	Only the old `System.Data` (ADO.NET)	Entity Framework Core, Dapper
Advanced/flexible JSON	`System.Text.Json` exists but can fall short in some polymorphic or legacy cases	Newtonsoft.Json (Json.NET)
Reactive programming (Rx)	Nothing built in	System.Reactive — despite the name, it's a separate NuGet package, not part of the core
Unit testing	Nothing built in	xUnit, NUnit, MSTest
Object-to-object mapping	Nothing built in	AutoMapper, Mapster
Advanced validation	Basic `DataAnnotations` exist	FluentValidation
Resilience (retry, circuit breaker)	Nothing built in	Polly, now becoming official through `Microsoft.Extensions.Resilience`
Complex time zone/calendar math	`TimeZoneInfo` exists but falls short in some edge cases	NodaTime
Image processing	Old `System.Drawing`, tied to Windows	SixLabors.ImageSharp, SkiaSharp
Desktop/mobile UI	Nothing built in	WPF, WinForms, .NET MAUI, Avalonia
AI / LLM integration	Nothing built in	`Microsoft.Extensions.AI`, Semantic Kernel
Messaging/queue systems	Nothing built in	MassTransit, RabbitMQ/Kafka clients

The general rule: System covers the basic needs of the language and the runtime. The layer that business apps actually need — web, DI, logging, ORM — comes from the Microsoft.Extensions.* family and the wider NuGet ecosystem.

Alongside these limits, some pieces have also been deliberately removed over time — that deserves its own section too.

Backward compatibility and what's been removed over time

BinaryFormatter — removed from newer .NET versions due to security risks. System.Text.Json is the recommended replacement.
CAS (Code Access Security) — largely dropped with .NET Core.
Remoting — replaced by modern HTTP/gRPC-based communication.
System.Drawing on non-Windows platforms — restricted on cross-platform .NET Core because of its dependency on Windows.

Enough theory — let's get practical. How can you actually see this namespace inside your own project?

Where can you actually see these default namespaces in your project?

1. ImplicitUsings: seeing your default usings in a real file

This feature, added in .NET 6, automatically adds the most common namespaces for your project type, so you don't have to write using System; in every single file. You can see this in a real file in three steps:

Step 1 — Make sure the feature is turned on. Your .csproj file should contain this line (it's already on by default in new projects):

<ImplicitUsings>enable</ImplicitUsings>

Step 2 — Find the file the compiler generates. After you build the project once (dotnet build), the compiler creates a file behind the scenes at this path:

obj/Debug/net10.0/<YourProjectName>.GlobalUsings.g.cs

Step 3 — Open it. Here's what your default usings really look like:

global using global::System;
global using global::System.Collections.Generic;
global using global::System.IO;
global using global::System.Linq;
global using global::System.Threading;
global using global::System.Threading.Tasks;

So even if you never open this file, these six namespaces are already available in every .cs file in your project. This is what "the default namespaces" really means.

2. Not all usings are the same

The global using you saw above is just one of a few different kinds of using:

Type	What it does	Example
`using`	Makes a namespace available in that one file only	`using System.Text;`
`global using`	Makes a namespace available in every file in the project	`global using System;`
`using static`	Lets you call a class's static members without writing the class name	`using static System.Math;` → now you can just write `Sqrt(4)`
`using X = Y` (alias)	Gives a long type name a short nickname, useful for resolving name clashes	`using Timer = System.Threading.Timer;`

3. The "Dependencies" node in your IDE

In Solution Explorer, expand Dependencies > Frameworks > Microsoft.NETCore.App to see exactly which assemblies System is split into, by their real DLL names.

4. The shared runtime folder on disk

Windows: C:\Program Files\dotnet\shared\Microsoft.NETCore.App\10.0.x\
Linux/macOS: /usr/share/dotnet/shared/Microsoft.NETCore.App/10.0.x/

5. "Go to Definition" to look inside

Press F12 on any System type, and your IDE decompiles and shows it to you automatically. You can also open System.Private.CoreLib.dll with a tool like ILSpy or dotPeek and browse all its classes as a tree.

Now that you've seen all this, let's answer a few questions that tend to come up.

Frequently asked questions

Is System a DLL? No. It's a namespace, and its contents are spread across multiple assemblies and NuGet packages.

Why does System.Object matter so much? It's the root of .NET's type system. Every value type and reference type comes from it.

What's the difference between System and Microsoft namespaces? System.* is closer to the core language and runtime. Microsoft.* covers tooling and higher-level frameworks.

Is System open source? Yes, it's developed in the open at github.com/dotnet/runtime.

Is it still being developed? Absolutely. A new major version ships every November.

Who develops System? Microsoft's .NET team leads the work, but since it's open source, independent contributors from around the world are involved too.

Reference section: namespaces and their types, in detail

For the curious reader — if you want to turn everything you've read so far into concrete class and interface names, this section is for you. If you'd rather move fast, feel free to skip it.

System (root level)

Classes and structs

Type	Kind	What it's for
`Object`	class	The ancestor of every type; `ToString()`, `Equals()`, `GetHashCode()` all come from here
`String`	class	Text handling; immutable
`Array`	class	The base class for all array types
`Convert`	class	Converting between types (`Convert.ToInt32`, etc.)
`Math` / `MathF`	class	Math operations (double / float versions)
`Random`	class	Random number generation
`Console`	class	Reading from and writing to the console
`Environment`	class	OS info, environment variables, process info
`Exception` and its subclasses	class	`ArgumentException`, `NullReferenceException`, etc. — the backbone of error handling
`Version`	class	Represents a version number
`WeakReference`	class	Tells the garbage collector "you can collect this if you need to"
`Uri`	class	Parsing and validating URLs/URIs
`Tuple`	class	Grouping multiple values together (reference type version)
`Lazy<T>`	class	Delays computing a value until it's first accessed
`DateTime`, `DateTimeOffset`, `TimeSpan`	struct	Date and time handling
`DateOnly`, `TimeOnly`	struct	Added in .NET 6, for date-only or time-only values
`Guid`	struct	Generating unique identifiers
`ValueTuple`	struct	Grouping multiple values together (value type version)
`Nullable<T>`	struct	Lets value types be nullable

Interfaces

Interface	What it's for
`IDisposable`	The contract for releasing unmanaged resources (files, connections, etc.)
`IComparable<T>`	Lets two objects be compared for sorting
`IEquatable<T>`	A specialized contract for equality checks
`ICloneable`	Marks an object as being able to be cloned
`IServiceProvider`	The core contract behind dependency injection systems — DI itself lives in `Microsoft.Extensions`, but this interface is defined in System

Delegates

Delegate	What it's for
`Action<T>`	Represents a method that doesn't return a value
`Func<T,TResult>`	Represents a method that returns a value
`Predicate<T>`	Represents a method that checks a condition and returns `true`/`false`

System.Collections.Generic

Classes: List<T> (a dynamic list), Dictionary<TKey,TValue> (key-value pairs), HashSet<T> (a set of unique items), Queue<T> (FIFO), Stack<T> (LIFO), LinkedList<T> (a doubly linked list), SortedList<TKey,TValue> and SortedSet<T> (auto-sorted structures).

Interfaces: IEnumerable<T> (lets you loop over a collection), ICollection<T> (add/remove/count), IList<T> (access by index), IDictionary<TKey,TValue> (key-value contract), IComparer<T> (custom sorting logic).

System.Linq

Classes: Enumerable (holds all the classic LINQ methods like Where, Select, OrderBy, GroupBy, Sum, Average for in-memory collections), Queryable (the same methods, but translatable into queries for outside sources like databases).

Interfaces: IQueryable<T> (lets a query be deferred/delayed — the foundation of ORMs like EF Core), IOrderedEnumerable<T> (lets you chain ThenBy after OrderBy for secondary sorting).

System.IO

Classes: File and Directory (static file/folder operations), FileInfo and DirectoryInfo (object-based info and operations), Path (combining paths, extracting extensions), Stream (the base class for all streams), FileStream, MemoryStream, StreamReader/StreamWriter.

System.Threading / System.Threading.Tasks

Classes: Thread, ThreadPool, Mutex, Semaphore, Monitor (the mechanism behind lock), Interlocked (atomic operations), Task/Task<T>, CancellationTokenSource, Parallel.

Structs: CancellationToken — carries the "should this be cancelled?" signal to an operation.

System.Text / System.Text.Json / System.Text.RegularExpressions

Classes: StringBuilder (efficient text building), Encoding (character encoding), JsonSerializer and JsonDocument (converting/inspecting JSON), Regex (regular expressions).

Structs: JsonElement — represents a single JSON value inside a JsonDocument.

System.Net.Http

Classes: HttpClient, HttpRequestMessage, HttpResponseMessage, HttpContent.

System.Reflection

Classes: Assembly (a compiled assembly), MethodInfo, PropertyInfo, FieldInfo — all let you inspect a type at runtime.

Note: Type, the class most often used alongside Reflection, is actually not defined in System.Reflection — it lives in the System root namespace.

System.Diagnostics

Classes: Debug (only runs in debug builds), Trace (runs in both debug and release), Stopwatch (measuring time), Process (managing external processes), Activity (distributed tracing).

System.Security.Cryptography

Classes: SHA256/SHA512 (hashing), Aes (symmetric encryption), RSA (asymmetric encryption), RandomNumberGenerator (cryptographically secure randomness).

System.Numerics

Structs: BigInteger (arbitrarily large integers), Complex (complex numbers), Vector<T> (SIMD-accelerated vector operations).

Interfaces: INumber<T> and INumberBase<T> — the foundation of generic math, defining shared math behavior across different numeric types.

Quick summary

System is not one class — it's a root-level namespace holding .NET's core building blocks.
It has its own sub-namespaces at level 1, level 2, and deeper; each level needs its own using.
Its contents fall into distinct roles — classes, structs, interfaces, delegates — and keywords like enum, struct, and delegate are backed by real System classes.
The CLR runs your code, CTS/CLS define the type rules, and BCL/FCL are the ready-made libraries built on those rules — System is the heart of the BCL.
It's been around since 2002 and is still actively developed every year.
It's intentionally kept limited — needs like web frameworks, DI, logging, and ORMs are covered by Microsoft.Extensions.* and the wider NuGet ecosystem.
You can see this namespace for yourself in GlobalUsings.g.cs, your IDE's Dependencies node, or the shared/Microsoft.NETCore.App folder on disk.
The evolution is still going, with .NET 11 previews shipping right now — the next big milestone is November 2026.

C#'ta Ters Hissettiren Polimorfizm

sadık emre — Sun, 26 Jul 2026 09:49:38 +0000

Bir metodun hangi sınıfa ait olduğu bazen göründüğü kadar net değil. C#'ta polimorfizm çoğu zaman beklendiği gibi çalışır, ama bazı durumlarda tam tersi olur ve bu hatalar genelde code review'a kadar fark edilmeden ilerler.

Aşağıda dört örnek var.

Hepsinde "hangi metot çalışır" sorusunun cevabı beklenenden farklı çıkıyor.

Sebebini örneklerden sonra birlikte açacağız.

1. Constructor İçinden Metot Çağırmak

public class MeyveSepeti
{
    public MeyveSepeti() => Hazirla();
    protected virtual void Hazirla() => Console.WriteLine("Sepet hazırlanıyor");
}

public class ElmaSepeti : MeyveSepeti
{
    private readonly string _meyveAdi = "Elma";
    public ElmaSepeti(string meyveAdi) { _meyveAdi = meyveAdi; }
    protected override void Hazirla() => Console.WriteLine($"Sepetten {_meyveAdi} alınıyor");
}

var sepet = new ElmaSepeti("Armut");
// Çıktı: Sepetten  alınıyor (meyve adı boş çıkıyor)

Beklenen çıktı "Sepetten Armut alınıyor" gibi görünüyor, ama öyle olmuyor.

Çağrılan metot ElmaSepeti'nin metodu oluyor, doğru. Ama o an _meyveAdi henüz hiç değer almamış, adı boş çıkıyor.

Roslyn (C#'ın kod analizi yapan derleyici altyapısı) bu durumu ayrı bir kuralla işaretliyor: CA2214. Kural, constructor içinde override edilebilir bir metot çağrıldığında uyarı veriyor. Projede açık değilse fark edilmeden geçebiliyor.

2. Aynı Sınıftaki Bir Metodun Başka Bir Metodu Çağırması

public class MeyveSepeti
{
    public virtual void SesVer() => Console.WriteLine("Sepetten ses geliyor");
    public void Duyur() => this.SesVer();
}

public class ElmaSepeti : MeyveSepeti
{
    public override void SesVer() => Console.WriteLine("Elma sepetinden ses geliyor");
}

ElmaSepeti sepet = new ElmaSepeti();
sepet.Duyur();
// Çıktı: Elma sepetinden ses geliyor

Duyur() metodu MeyveSepeti'de yazılı.

Ama çalıştığında ElmaSepeti'nin metodunu çağırıyor.

3. `new` ile Metot Gizleme

public class MeyveSepeti
{
    public void Tanit() => Console.WriteLine("Bu bir meyve sepeti");
}

public class ArmutSepeti : MeyveSepeti
{
    public new void Tanit() => Console.WriteLine("Bu bir armut sepeti");
}

MeyveSepeti sepet = new ArmutSepeti();
sepet.Tanit();
// Çıktı: Bu bir meyve sepeti

Nesne gerçekte bir ArmutSepeti.

Ama çıktı "Bu bir armut sepeti" değil, "Bu bir meyve sepeti" oluyor.

4. Sadece Interface Üzerinden Görünen Metot

public interface IKapasiteHesaplanabilir
{
    double Kapasite();
}

public class MeyveSepeti : IKapasiteHesaplanabilir
{
    private readonly double _boyut;
    public MeyveSepeti(double boyut) => _boyut = boyut;
    double IKapasiteHesaplanabilir.Kapasite() => _boyut * _boyut;
}

var sepet = new MeyveSepeti(4);
// sepet.Kapasite(); -> derleme hatası

IKapasiteHesaplanabilir kapasiteli = sepet;
kapasiteli.Kapasite();
// Çıktı: 16

sepet.Kapasite() hiç çalışmıyor, derleme hatası veriyor.

Aynı metot, kapasiteli.Kapasite() olarak yazınca çalışıyor.

Peki Bu Dördünün Sebebi Ne?

Dört örnek de aynı sebepten değil, iki ayrı sebepten kaynaklanıyor.

Birinci sebep: nesne oluşurken ayarlanan bir bilgi

new ElmaSepeti(...) çalıştığında sırayla şunlar olur:

Nesne için bellekte yer ayrılır.
Bu nesneye, "sen bir ElmaSepeti'sin" bilgisi hemen o anda iliştirilir. Bu bilgi, henüz hiçbir constructor çalışmadan hazır olur.
Sonra MeyveSepeti'nin constructor'ı çalışır.
Bu constructor içinde bir metot çağrıldığında, çalışma zamanı nesneye iliştirilmiş olan bu bilgiye bakar ve "bu aslında bir ElmaSepeti, o zaman ElmaSepeti'nin metodunu çalıştır" der.
MeyveSepeti'nin constructor'ı bittikten sonra ElmaSepeti'nin kendi alanları değer alır.
En son ElmaSepeti'nin constructor gövdesi çalışır.
örnekte sorun burada: 4. adım, 5. adımdan önce oluyor. Metot doğru sınıfa ait ama alan henüz boş.
örnekte de aynı 4. adım işliyor, ama bu sefer nesne tam kurulmuş durumda, bu yüzden sonuç aslında doğru. Sürpriz olan tek şey, MeyveSepeti içinde yazılan bir kodun ElmaSepeti'nin metodunu çalıştırabilmesi.

İkinci sebep: derleyicinin önceden verdiği karar

3 ve 4. örnekler bambaşka bir yerden geliyor. Burada çalışma zamanı hiçbir şeye bakmıyor.

Kod daha derlenirken, derleyici değişkenin hangi tipte tanımlandığına bakıyor ve çağrının nereye gideceğine orada karar veriyor.

örnekte sepet değişkeni MeyveSepeti tipinde tanımlı. Derleyici bu yüzden çağrıyı MeyveSepeti'nin metoduna bağlıyor, nesnenin gerçekte ArmutSepeti olması hiç önemli değil.
örnekte ise Kapasite() metodu, MeyveSepeti'nin normal bir üyesi olarak bile tanımlanmamış. Derleyici sepet.Kapasite() yazıldığında bu metodu MeyveSepeti'nin listesinde bulamıyor, hata veriyor.

Özetle: 1 ve 2, nesneye iliştirilen gerçek tip bilgisinden kaynaklanıyor. 3 ve 4 ise derleyicinin değişkenin tanımlı tipine bakarak verdiği erken karardan.

Kaçınma Yolları

Constructor içinde başka bir metot çağırmaktan kaçınmak. Bunun yerine nesneyi ayrı bir metotla, tam kurulduktan sonra hazırlamak.
Bir sınıfın kendi metodu başka bir metodunu çağırdığında, bunun alt sınıfta değişebileceğini akılda tutmak.
override ve new arasındaki farkı her zaman açıkça yazmak.
Interface üzerinden yazılan bir metodu çağırırken hangi tipteki değişkeni kullandığına dikkat etmek.
CA2214 kuralını projede açık tutmak.

Sonuç

Dört örnek de "hangi metot çalışır" sorusunun cevabının, göründüğünden daha karmaşık olabileceğini gösteriyor.

Bazen bu cevap nesneye iliştirilen gerçek tip bilgisine bağlı, bazen de derleyicinin daha en baştan verdiği bir karara.

C#’ta Parametre Geçişi: Referans Tiplerde Gözden Kaçan Nokta

sadık emre — Fri, 17 Jul 2026 19:46:54 +0000

Bir metoda string ya da bir nesne parametre olarak verilip metot içinde bu parametreye yeni bir değer atandığında, çoğu zaman çağıran taraftaki değişken de değişmiş sanılır. Aşağıdaki örnek bu varsayımı çürütüyor — ve çürüme sebebi, çoğu geliştiricinin sandığından farklı.

Önce kafa karıştıran örnek

void TestMetot(string A)
{
    A = "Naber!";
}

string A = "Selam";
TestMetot(A);
Console.WriteLine(A); // Selam

Metot içinde A'ya açıkça "Naber!" atanmasına rağmen çıktı "Selam". Derleyici için burada iki bağımsız A var: metot dışındaki A ve parametredeki A. Bunlar aynı isme sahip ama birbirinden habersiz iki ayrı kutu (değişken).

string A = "Selam" çalıştığında ortaya çıkan tablo:

Stack:
  metot dışındaki string A, RAM'de 0x100 bellek adresini tutar

Heap:
  0x100 adresine karşılık gelen değer "Selam"dır.

TestMetot(A) çağrıldığında, parametredeki A adında yeni bir kutu açılıyor ve bu kutuya metot dışındaki A'nın tuttuğu adres (0x100) kopyalanıyor. A = "Naber!" çalıştığında ise sadece bu yeni kutu güncelleniyor, metot dışındaki A hiç etkilenmiyor.

Asıl soru: neden ikinci bir referans oluşuyor?

Buradaki gerçek soru "neden string beklenmedik davranıyor" değil. Asıl soru şu: metoda bir referans verildiğinde, C# neden onu olduğu gibi kullanmak yerine bir kopyasını çıkarıyor?

Cevap: Bu, string ya da başka bir reference type'a özgü bir istisna değil — C#'ta parametre geçişinin varsayılan ve tek kuralı bu. Metoda ne verilirse verilsin (sayı, string, nesne, fark etmez), çağıranın kutusunun kendisi değil, o kutunun o anki içeriğinin bir kopyası metoda girer. int için kopyalanan içerik doğrudan sayının kendisi, string/List için kopyalanan içerik bir adres — ama kopyalanma kuralı ikisinde de birebir aynı. Yani "referans tipi geçince otomatik bağlantı kurulur" diye bir istisna hiç yok; asıl yanlış varsayım burada.

Bu tasarımın bir sebebi var. Eğer metoda bir referans verildiğinde metot, çağıranın kutusunun kendisine erişebilseydi, şöyle bir risk her zaman var olurdu:

void Guncelle(List<int> A)
{
    A = new List<int>(); // çağıranın değişkenini TAMAMEN BAŞKA bir nesneye çevirebilirdi
}

Bu otomatik yansısaydı, herhangi bir metoda bir nesne verildiğinde o metodun, çağırandaki değişkeni sessizce başka bir nesneye yönlendirme ihtimali her zaman var olurdu. Kodu okuyan biri her çağrıda "bu metot benim değişkenimi başka bir şeye çevirmiş olabilir mi?" diye düşünmek zorunda kalırdı.

Kutunun kopyalanması bu riski ortadan kaldırıyor. Metot kendi parametresini istediği gibi başka adreslere yönlendirebilir, ama bu sadece kendi kopyasını etkiler. Çağıranın hangi nesneye baktığı garanti altında kalır — metodun çağırandaki değişkeni gerçekten yönlendirebilmesi isteniyorsa, bu ref/out ile açıkça talep edilmek zorunda. "İkinci referans" bir yan etki değil, bilinçli bir güvenlik/öngörülebilirlik tercihi.

`int` için de aynı kural işliyor

void TestMetot(int A)
{
    A = 99;
}

int A = 5;
TestMetot(A);
Console.WriteLine(A); // 5

Heap araya girmiyor ama mekanizma birebir aynı: parametredeki A kutusu açılıyor, metot dışındaki A'nın değeri kopyalanıyor, A = 99 sadece kopyayı değiştiriyor. Bu örnek genelde şaşırtmaz, çünkü value type olduğu bilinir — asıl fark string örneğinde "reference type olmasına rağmen" aynı sonucun çıkmasıdır.

Bazı örnekler neden çalışıyor gibi görünüyor?

void TestMetot(List<int> A)
{
    A.Add(5);
}

var A = new List<int>();
TestMetot(A);
Console.WriteLine(A.Count); // 1

Burada da iki ayrı kutu var, ikisi de aynı adresi tutuyor. Fark, metot içinde yapılan işlemde: A.Add(5) kutunun içeriğini (adresi) değiştirmiyor, kutunun tuttuğu adresteki nesnenin kendisini güncelliyor. İki kutu hâlâ aynı adresi tuttuğu için değişiklik her iki taraftan da görünür.

Mutation (nesnenin içini değiştirmek): A.Add(...), sb.Append(...) → kutunun içeriğine dokunulmaz, otomatik yansır.
Reassignment (kutunun içeriğini değiştirmek): A = "Naber!", A = new List<int>() → kutu başka bir adres tutmaya başlar, yansımaz.

string immutable olduğu için (Add, Remove gibi mutation işlemi yoktur) üzerinde yapılan her işlem zorunlu olarak reassignment'tır — bu yüzden string ile bu tuzağa düşmek çok daha kolaydır.

`ref`/`out` ne zaman gerekir?

void TestMetot(ref string A)
{
    A = "Naber!";
}

string A = "Selam";
TestMetot(ref A);
Console.WriteLine(A); // Naber!

ref verildiğinde metot ayrı bir kutu açmaz, doğrudan çağıranın kutusuna erişir — o yüzden reassignment de yansır. out aynı mekanizmayı kullanır, tek farkı: çağıranın başlangıç değeri vermesi gerekmez ama metodun out parametresine mutlaka bir değer ataması zorunludur, aksi hâlde derleme hatası alınır.

Neden önemli?

Bu davranış hiçbir exception fırlatmaz, hiçbir uyarı vermez. Bir metodun bilgi hesaplayıp parametre üzerinden geri döndürmesi beklenen her yerde — loglama, id üretme gibi yardımcı metotlarda — sonuç sessizce hep boş/varsayılan gelir ve fark edilmesi haftalar sürebilir.

İlgili konular

StringBuilder: string'in mutable karşılığı, .Append() mevcut nesneyi günceller.
in parametresi: büyük struct'ları kopyalamadan, salt-okunur geçirmek için.
Closure'larda değişken yakalama: lambda'lar dış değişkeni kutu olarak yakalar, değeri değil — aynı kök mantık.
record ve with: immutable tiplerde "değiştirme" aslında yeni nesne üretir, string'in Substring'ine benzer.