DEV Community: sadık emre

About VPN: Questions and Answers

sadık emre — Sun, 23 Aug 2026 11:13:57 +0000

PART 1: Connecting to a Company VPN

1. What is a VPN, what is its basic purpose?

A VPN (Virtual Private Network) is a system that encrypts the traffic leaving your device and carries it, inside a private "tunnel," over your existing internet connection to another point (the VPN server). The purpose is to hide your traffic from eyes on the local network and the ISP, and/or to connect to a remote private network (such as a company network).

This definition contains a few terms. We'll cover each of them in detail in later sections, but let's first define them all briefly in one place. That way the terminology won't be confusing.

Common basic terms:

Encryption: Turning data into a form that no one without the right key can read.
Encapsulation: Adding a new address label to the outside of encrypted data, showing where it should go.
Tunnel / Tunneling: The method that results from applying encapsulation and encryption to every packet, consistently and systematically, throughout a connection. "Tunnel" is the name of the virtual connection set up this way.
VPN client: The VPN app you install on your device, which does the encryption and encapsulation.
VPN server: The computer at the other end of the tunnel that decrypts the data and forwards it to the real destination.
Private IP (internal IP): An address that's only valid inside a specific private network.
Public IP (external IP): The address visible on the internet, given by your ISP.
ISP: The company that provides your internet connection.
NAT: The router hiding internal IPs behind the public IP.
Packet / IP packet: The unit of data carried on a network, which carries address information.
Split tunnel / Full tunnel: Whether only certain traffic, or all traffic leaving the device, goes through the tunnel.

2. When you connect to a company VPN, what path does a data packet follow?

Device

→ VPN client: the VPN app installed on your computer (encrypts and wraps the data)

→ Internet (encrypted tunnel)

→ VPN server: the computer run remotely by the company or the provider you use (decrypts the data, forwards it to the real destination)

→ Destination server: a service/database inside the company

→ the response comes back the same way

3. How does encapsulation happen?

Imagine you're writing "Hi" to a friend. Both of these steps are done by the VPN app installed on your computer:

Encryption: The VPN app turns the word "Hi" into something meaningless (example: X7!ap4b#tr), which only the VPN server can decode.
Putting it in a new envelope: The VPN app then adds a new, readable address label around this encrypted data: [From: your public IP | To: VPN server] X7!ap4b#tr.

Think of it like an envelope in the mail: the address on the outside can be read by the postal service (the routers), but the letter inside is sealed, and only the recipient (the VPN server) can open it.

4. Does encryption happen on the device, and is that how the data leaves for the internet?

Yes. Here's the order:

Encryption and wrapping happen on your computer, done by the VPN app, before the data leaves for the internet.
The finished packet (readable outer address, encrypted inner part) goes to your home router (modem).
The router sends it to the ISP.
The ISP only looks at the outer (unencrypted) address and forwards it; it can't read the content.
The packet reaches the VPN server, where it gets decrypted.

It always passes through the ISP before reaching the VPN server.

5. When the VPN assigns a private IP, how do authentication and joining the network work?

There are two stages.

Stage 1: Authentication. The VPN server has a public IP address. You connect to it using your own real public IP; since you don't have a private IP yet, there's no other way to connect. You prove your identity through methods like a password or a certificate. Some systems also add extra security, such as a rule that only accepts connections from certain public IPs, but the actual authentication is done with a password or certificate.

Stage 2: Joining the network. Once your identity is confirmed, you're given a private IP (like 10.8.0.15). Since the company's other servers are also part of the same private network (10.x.x.x), you can reach each other using these private IPs. The VPN server acts as the bridge/gateway between you.

Can the destination server see your public IP? No, it only sees your private IP (10.8.0.15). The VPN server doesn't change the source address when it forwards the packet. The destination server may also have a firewall rule in front of it, such as "only accept requests coming from the VPN's private IP range." This is a separate, extra layer of security on top of authentication.

6. What happens when you access an address that doesn't belong to the company (like YouTube) while connected to the VPN?

This depends on whether the VPN is running in split tunnel or full tunnel mode (see 2.3).

Split tunnel (common, default behavior):

Only traffic going to the company's private network goes through the tunnel.

General internet destinations like YouTube never enter the tunnel; they go out directly through your normal internet connection.

Result: you go out with two different IPs at the same time. Company traffic goes through the VPN, and everything else goes through your own connection.

Full tunnel (some companies enforce this):

All traffic, including YouTube, first goes to the VPN server, then goes back out to the internet from there.

Result: everywhere you go sees you as if you're coming from the VPN server.

In both modes, your actual internet connection never changes. What changes is where your traffic exits from in the last step.

7. At which stages does a VPN provide security, and where doesn't it?

The path:

Device

→ Local network (your home/office WiFi) + ISP

→ VPN server

→ Destination server

The VPN protects the path from your device to the VPN server. It hides you from eyes on the local network (other devices on the same WiFi) and at the ISP.

But protection ends between the VPN server and the destination site. That part is the open internet.

If the site uses HTTPS, that part is protected by its own TLS encryption (a separate mechanism, independent of the VPN). If it uses HTTP, it's completely open.

Also, the VPN server itself can see your traffic, because it has to decrypt it in order to forward it. So using a VPN doesn't mean "no one can see this"; it means "the local network and the ISP can't see it, but my VPN provider can."

Note: if the tunnel drops unexpectedly, there's a feature that stops your traffic from silently continuing without encryption. This is called a kill switch (see 3.5).

PART 2: Details (Explanations That Complete the Basic Mechanics)

2.1 Terms and Concepts

In Part 1 we touched on a few terms in passing. Let's explain them here.

Is the VPN concerned with the NAT/private IP setup on your home network, or does it create its own network?

Private IP: The address the router gives to devices on the local network (like 192.168.x.x). Only meaningful inside that local network.
Public IP: The address your ISP gives you, visible on the internet.

The router hides the private IP behind the public IP. This is called NAT.

The VPN has nothing to do with this NAT/private IP setup on your home network, and doesn't touch it. Whether or not you connect to the VPN, your private IP on the home network stays the same.

What the VPN actually cares about is something else entirely: it sets up its own separate network, and assigns you a private IP that it gives you on that network (like 10.8.0.15). This is a brand-new network specific to the VPN, independent of the NAT on your home network.

What is an ISP?

Internet Service Provider: a company like Türk Telekom or Vodafone that gives you internet access and a public IP.

Where does the term "tunneling" come from, and why is it confused with encryption?

The name comes from a tunnel that goes through a mountain: vehicles enter from one end and exit from the other, and while inside, they're invisible from the outside. So the name means "opening a private path through a public network, without mixing into it." It's not directly related to encryption. In fact, some old tunneling protocols (like GRE) don't do any encryption at all.

Why can't I see my public IP from the command line (cmd)?

ipconfig only shows the local settings your device knows about; it doesn't show your public IP. But if you use a command that sends a request out and waits for a reply, like curl ifconfig.me, you can find it out.

2.2 Network Layers

Encapsulation (Part 1, item 3) is actually a general principle of networks applied to VPNs. This principle is called a "layer."

Why does the concept of a layer exist, and where does the name come from?

Network communication is split into independent tasks stacked on top of each other. Each layer does its own job and relies on the layer below it. They're called "layers" because they're stacked like layers of a cake. The benefit: you can change one layer (like WiFi instead of fiber) without affecting the others.

What are the network layers?

Physical layer: carries raw bits.
Data link layer: connects devices on the local network using MAC addresses.
Network layer (IP): routes between different networks.
Transport layer (TCP/UDP): separates applications using port numbers.
Application layer: the actual data, like HTTP, DNS, TLS.

How do the layers work independently of each other?

Like mail: letter (data) → envelope (port) → box (IP) → courier routing (MAC) → physical transport. The courier doesn't read the letter; they only look at the label for their own layer. So if one layer changes (a truck instead of a plane), the layers above it aren't affected.

What is an IP packet, how is it different from a data packet?

"Packet" is the name for the envelope at whichever layer you're talking about. An "IP packet" is specifically the envelope that has an IP address written on it. It's not a separate thing; it's a member of the same family.

2.3 Inside Tunneling

Now let's look at how a VPN uses these layers, and whether encapsulation has a size limit.

Does every packet go through encapsulation?

No. When the VPN connects, a rule is added to the operating system: "A packet going to the company network → send it through the tunnel, encapsulated. Everything else → send it the normal way." (See Part 1, item 6: split tunnel.)

Is there a size limit on encapsulation?

Yes. A network connection can carry only a certain amount of data at once. This is called the MTU; on Ethernet, this is usually 1500 bytes.

How does the header added by the VPN cause some websites to fail to load?

If a packet is already close to 1500 bytes, the extra header added by the VPN (about 30-60 bytes) pushes the total over that limit. As a result, the packet either gets split in two (many firewalls block this) or a warning message gets stuck at a firewall, and the connection hangs for no obvious reason.

Small requests (text, DNS) aren't affected; larger content (video, images) gets stuck. The fix: the VPN sets the tunnel interface's MTU lower from the start (like 1400), so packets are already produced smaller.

2.4 How Does a VPN Get Between the Layers?

So how does the VPN software actually become part of this layer system?

What is a virtual network interface?

An interface is the point where two systems meet, like an electrical outlet. It's normally something physical (like a WiFi chip), but software can create a fake one; the operating system treats it as real.

How does the VPN create this interface? Is it interfering with the system without permission?

Operating systems leave an official door open for exactly this purpose: TUN/TAP. With admin permission, the VPN uses this door and says "I'm an interface too." The operating system doesn't care which card it's using.

What is TUN/TAP?

TUN only carries IP packets (most VPNs use this). TAP behaves like a full Ethernet card, and is used to merge two networks so they act like one.

Doesn't this require serious system-level permission?

Yes. That's why installing a VPN asks for admin rights. Legitimate software like antivirus programs and firewalls use the same mechanism, but which VPN you trust matters.

2.5 Types of VPN

These different layers and mechanisms translate, in practice, into different types of VPN.

How are VPN types classified by purpose?

Remote access VPN: A single user connects to a company network.
Site-to-site VPN: Two office networks connect to each other.
Personal/commercial VPN (like NordVPN): Connects you to the provider's own server.

What is an IPsec VPN?

IPsec (Internet Protocol Security) is a family of encryption and authentication protocols that works at the network layer (IP level). It creates a tunnel interface on the device (see 2.4) and encrypts all traffic leaving that device, no matter which app or port, sending it through the tunnel. Because of this, a separate VPN client app usually needs to be installed. It's one of the most common approaches used in company VPNs (Part 1).

What is an SSL VPN?

An SSL VPN gets its name from TLS/SSL encryption, meaning it uses the same mechanism that's behind HTTPS. Unlike IPsec, it works higher up, at the application level, instead of the network layer. This makes it more selective: it can tunnel a specific app or web-based service instead of all the traffic on the device. Some SSL VPNs can even provide access directly through a browser ("clientless"), without installing a separate program.

What are modern alternatives to traditional VPNs?

Mesh VPN (like Tailscale, ZeroTier): In a classic VPN, traffic always goes through a central server. In a mesh VPN, the central server just helps devices find each other (see 3.4); the actual traffic flows directly between devices. It's quick to set up, and is generally preferred by small teams for secure access to their own servers (see 2.6).

ZTNA (Zero Trust Network Access) / SASE: In a classic VPN, once you're in the tunnel, you have access to most of the network; a single compromised account can put the whole network at risk. ZTNA instead verifies every request separately; the user can only reach the specific app they're authorized for, and never sees the rest of the network. SASE turns this approach into a security/network service package delivered through the cloud.

2.6 Peer-to-Peer Tunnel

Up to this point, there was always a central VPN server. In peer-to-peer, that goes away.

What is a peer-to-peer tunnel?

Think of an old-style phone switchboard: normally the switchboard (the VPN server) sits in the middle of every conversation. In peer-to-peer, the switchboard just introduces the two sides, then steps out, and the devices talk directly.

What's the security difference compared to a centralized system?

In a centralized system, if the server is compromised, everything can be read. In peer-to-peer, the helper server never sees the encryption, so even if it's compromised, the traffic can't be read.

What are the benefits of setting up a personal mesh network?

With tools like Tailscale/ZeroTier, you can connect to each other using private IPs and set up a secure network that's closed off from the outside. If you want, you can turn one device into an "exit node" and go out to the internet through it as well. (See 3.4 for the technical details of how two devices find each other.)

2.7 DNS and DNS Leaks

A VPN doesn't just affect IP traffic; it also affects domain name lookups.

What is a DNS server?

A server that translates a domain name (example.com) into an IP address.

How are DNS queries normally handled while connected to a VPN?

When the VPN is working correctly, your DNS queries go through the encrypted tunnel, like the rest of your traffic, to the VPN provider's own DNS server. So even the question "what site do I want to go to" stays inside the tunnel, in a way the ISP can't see.

How does a DNS leak happen while using a VPN?

If the VPN fails to route these queries to its own server, the device still asks the old (ISP) DNS server. These queries go out unencrypted, outside the tunnel. This means which sites you visit ends up leaking to the ISP.

2.8 Censorship and Obfuscation

Finally, let's look at whether a VPN itself can be blocked.

Can VPN access be blocked at the state level?

Yes. Known VPN server IPs can be blocked, or DPI can be used to recognize the "pattern" of the traffic and stop it.

What is DPI (Deep Packet Inspection)?

DPI is when a network device tries to figure out what kind of connection is passing through, not just by looking at the destination address, but by looking at the general "behavior" of the packet (its size, timing, handshake pattern, and so on). It can't read the content because it's encrypted, but it can guess "this looks like a VPN handshake" and block the traffic.

What is obfuscation?

Dressing up a VPN packet to look like normal HTTPS traffic. DPI mistakes it for an ordinary website visit.

PART 3: Advanced Topics

This section briefly rounds out the picture with more intermediate-to-advanced, practical and architectural topics, after you've learned the basic mechanics.

3.1 Comparing VPN, Proxy, and Tor

All three are often confused with each other, but they work at different layers and with different trust models.

What is a proxy, what is it used for?

A proxy is a simple middleman that forwards your requests through another server on your behalf. It's usually specific to a single app (mostly the browser) and doesn't encrypt traffic. Its purpose isn't privacy; it's mostly just to change your IP/location. It's typically used for simple scenarios, like getting around a regional content restriction.

What is Tor, what is it used for?

Tor (The Onion Router) is a network that routes your traffic through three randomly chosen volunteer servers, encrypting each layer separately. Its purpose is maximum anonymity: it's used in scenarios where hiding your identity is critical, such as journalism, avoiding censorship, or sensitive research. The cost is a noticeable slowdown, because it passes through three servers.

Feature	Proxy	VPN	Tor
Scope	Usually a single app	OS-level, all traffic	Usually the browser
Encryption	Mostly none	Yes	Yes, three layers
Point of trust	Proxy provider	VPN provider	No single node knows both source and destination
Speed	Fast	Medium	Slow

A proxy only changes your IP; it doesn't encrypt.

A VPN encrypts all your traffic and routes it through a single server.

Tor routes traffic through three different servers; the entry node knows who you are but not the destination, and the exit node knows the destination but not who you are.

Tor is the most private option, but also the slowest.

3.2 Performance Differences Between Protocols

In the context of a VPN, a protocol is a shared set of rules that both sides (your device and the VPN server) agree on in advance, about how to set up the tunnel, how the data will be encrypted, and how packets will be encapsulated. In other words, a protocol is "the actual method/technology that does the tunneling"; a VPN can only work through a protocol it has chosen.

Why is a protocol needed at all? Because two different devices, your computer and the VPN server, possibly with different operating systems and hardware, need a shared "language" and a fixed sequence to talk to each other without issues: how they'll introduce themselves, how they'll exchange keys, what format they'll package the data in, and so on. These rules make different vendors' VPN software compatible with each other not because they aren't standardized, but precisely because they are standardized.

Let's first get familiar with the common VPN protocols:

PPTP: One of the oldest VPN protocols. It's simple to set up, but its security is considered weak by today's standards, so it shouldn't be used anymore.
L2TP/IPsec: L2TP sets up the tunnel structure, and IPsec provides the actual encryption. The two are usually used together.
IKEv2/IPsec: Especially common on mobile devices. It can keep the connection alive without dropping it when the network changes (for example, switching from WiFi to mobile data).
OpenVPN: An open-source protocol based on TLS/SSL. It's been one of the most widely used options for a long time, with broad device and operating system support.
WireGuard: A newer, open-source protocol with a small, simple codebase. It stands out for both speed and simplicity, and is preferred by many VPN apps today.

Why are some VPN protocols faster than others?

There are a few reasons:

Codebase size: a small codebase runs faster and is easier to audit.
Where it runs: protocols that run in the operating system kernel have less delay than ones that run in user space (no extra handoff layer needed for each packet).
Encryption algorithm: some algorithms (like AES) benefit from hardware acceleration circuits on modern CPUs (AES-NI); others (like ChaCha20) are designed to run fast in software even without hardware acceleration. Which one is faster depends on the hardware being used.
Number of handshake steps: a handshake with fewer steps lets the connection re-establish faster, especially when the network changes (like switching from WiFi to mobile data).

3.3 Advanced Encryption Concepts

What is Perfect Forward Secrecy (PFS)?

Let's first recall two concepts. A key is a usually long, random sequence of numbers used to encrypt/decrypt data; someone without the right key can't read the encrypted data. Key exchange is the process where the two sides (the device and the VPN server) securely agree on this shared secret key; this happens right when the connection is being set up, just before the tunnel opens.

If the shared key produced during key exchange always stayed the same, it being compromised later would expose all past traffic. PFS ensures that a new, temporary key is generated for every session. This way, if a key is compromised, it only affects a short period, and past records stay safe.

What are certificates and PKI (Public Key Infrastructure)?

A certificate is a digital document, signed by a CA (Certificate Authority), that says "this public key really belongs to this server." Mutual TLS (mTLS): not just the server, but the client also presents its own certificate, so both sides prove who they are to each other.

3.4 NAT Traversal: How a Peer-to-Peer Connection Gets Established

How do two devices find each other and connect directly?

This is called "hole punching." The process involves three different components; two are servers, and one is a method/algorithm.

STUN server: A server computer running on the internet, with a fairly simple job. A device connects to it and asks, "what IP and port do you see me as from the outside?" and STUN answers. This is how a device learns how it appears from outside its own router. This is information the device normally couldn't know on its own.

ICE (Interactive Connectivity Establishment): Not a server. It's a method that both devices run on their own side. It tries several possible connection paths, including the addresses learned from STUN, one by one, and picks whichever one actually works.

TURN server: A server that runs on the internet, like STUN, but with a different job. When a direct connection can't be made between two devices, it relays the data itself, through its own connection. Think of it like a post office: a middleman that steps in and carries the letter when it can't be delivered directly. In this case, the connection is no longer truly peer-to-peer, because the TURN server can see the traffic. It's used as a last resort, when other methods don't work.

3.5 Kill Switch

What is a kill switch, and why does it matter?

If the tunnel drops suddenly, the operating system usually keeps going without the VPN, silently. This means unencrypted traffic can leak without you noticing. A kill switch stops all traffic the moment the tunnel drops; no packet goes out until the tunnel is re-established.

3.6 IPv6 Leaks

What is an IPv6 leak?

Most VPNs only route IPv4 traffic through the tunnel, and can forget about IPv6. If IPv6 is enabled on the device, this traffic can go out unencrypted, outside the tunnel. The fix: have the VPN route IPv6 through the tunnel as well, or turn IPv6 off on the system.

3.7 VPN Detection and Chaining

How do services like Netflix detect users who are using a VPN?

Through signs like lists of known VPN provider IPs, a large number of accounts connecting from the same IP, and the IP being in a "datacenter" range instead of a home/mobile one.

What is a datacenter? It's a range of IPs belonging to hosting/cloud companies that host servers in data centers, rather than to home/mobile users. A regular home user's IP comes from a range that belongs to an ISP; since VPN servers usually run from this kind of data center IP, a connection coming from a "datacenter" range is a strong sign that a VPN is being used.

What is Double VPN (VPN chaining)?

Traffic passing through two VPN servers, one after the other. Benefit: compromising a single server isn't enough. Cost: latency increases significantly.

3.8 VPN at Cloud and Enterprise Scale

What is Cloud VPN, how is it different from VPC peering?

Cloud VPN is a method for connecting a company's own physical office or data center network to a cloud provider's virtual network (VPC/VNet), such as AWS or Azure. The logic is the same as the site-to-site VPN in Part 1: since there's a public internet between the two separate networks, they're connected through an encrypted tunnel.

VPC peering describes a different scenario. Here, both networks already sit inside the same cloud provider's own internal infrastructure, and traffic never goes out to the public internet. The connection flows over the provider's own private backbone, and access is controlled through the provider's own permission and firewall rules.

In short: Cloud VPN encrypts a connection that travels over the internet. VPC peering directly joins a connection that stays within the cloud provider's own network.

Is there something similar to a VPN in Kubernetes?

Some network plugins (CNI) encrypt traffic between pods. A service mesh (like Istio, Linkerd) provides similar security at the application level, using mTLS.

What is SD-WAN, how does it work?

Think of a company with many branches: each branch may have multiple tunnels reaching headquarters through different types of connections (like a dedicated line, regular fiber internet, or a backup mobile line). In the classic approach, which traffic goes over which line is set manually and stays fixed.

SD-WAN (Software-Defined WAN) manages this automatically, through central software:

It continuously measures the real-time status of the available connections (latency, packet loss, cost).
It decides based on how important the traffic is. For example, it might route a video call over the lowest-latency line, and a file backup over the cheapest line.
If a line fails, it automatically shifts traffic to another line, without needing a person to step in.

Most of these tunnels are already encrypted with VPN protocols (like IPsec); SD-WAN adds a smart routing layer on top of the tunnels that already exist. In short: site-to-site VPN solves "how do you set up a tunnel," while SD-WAN solves "how do you best distribute traffic across many tunnels."

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.