Jak działa program w C# — od kodu do wykonania

Kąt widzenia: model mentalny działania programu C# — co się naprawdę dzieje między napisaniem kodu a uruchomieniem aplikacji, zanim zaczniesz uczyć się składni
Przykład przewodni: prosta aplikacja konsolowa i to, co kryje się za dotnet run

Problem z uczeniem się składni bez modelu mentalnego

Większość kursów zaczyna od: “wpisz Console.WriteLine("Hello, World!") i kliknij Run.” Program działa. Pięknie.

Ale potem pojawia się błąd i nie wiesz czy to problem z kodem, z kompilacją, z runtime, z konfiguracją — i nie masz pojęcia, gdzie szukać. Diagnozowanie błędów bez zrozumienia jak program działa to jak naprawianie silnika bez wiedzy, że silnik ma tłoki.

Ten post daje Ci ten model mentalny. Nie musisz rozumieć wszystkiego głęboko — musisz wiedzieć co się dzieje i dlaczego.

Trzy warstwy między kodem a wykonaniem

Kiedy piszesz kod C# i klikasz “Run” (lub wpisujesz dotnet run), dzieją się trzy osobne rzeczy:

Kod źródłowy (.cs)
        ↓
    Kompilacja (Roslyn)
        ↓
 Kod pośredni IL (.dll)
        ↓
   JIT Compilation (CLR)
        ↓
  Kod maszynowy (CPU)

Każda warstwa odpowiada na inne pytania i generuje inne błędy. Jeśli wiesz, na którym etapie coś się psuje — wiesz gdzie szukać.

Warstwa 1 — Kompilacja: Roslyn czyta Twój kod

Kiedy budujesz projekt (dotnet build), kompilator C# — Roslyn — czyta Twoje pliki .cs i zamienia je na IL (Intermediate Language), zwany też CIL lub MSIL.

IL to nie jest kod maszynowy. To język pośredni — coś między C# a instrukcjami procesora. Wynik kompilacji to plik .dll (lub .exe na Windows), który zawiera ten IL.

Co sprawdza Roslyn na tym etapie:

// Roslyn wykryje ten błąd PRZED uruchomieniem:
int liczba = "hello";  // CS0029: Cannot implicitly convert type 'string' to 'int'

// Roslyn wykryje użycie niezadeklarowanej zmiennej:
Console.WriteLine(wynik);  // CS0103: The name 'wynik' does not exist in the current context

Błędy kompilacji to Twój przyjaciel. Roslyn sprawdza logikę typów, czy zmienne istnieją, czy metody mają poprawne sygnatury — zanim program w ogóle zacznie działać. To jeden z powodów, dla których C# (język statycznie typowany) jest bezpieczniejszy niż Python czy JavaScript w dużych projektach.

Co oznacza “statycznie typowany”

W C# typ każdej zmiennej jest znany w czasie kompilacji:

string imie = "Anna";    // kompilator wie: imie to string
int wiek = 30;           // kompilator wie: wiek to int

imie = wiek;             // błąd kompilacji — kompilator złapie to natychmiast

W języku dynamicznie typowanym (Python, JavaScript) podobny błąd wyjdzie dopiero w runtime — gdy program już działa, być może na produkcji, być może po godzinie działania.

Warstwa 2 — CLR: środowisko uruchomieniowe

Skompilowany IL trafia do CLR (Common Language Runtime) — to środowisko, które uruchamia programy .NET. CLR odpowiada za:

• JIT (Just-In-Time Compilation) — tłumaczenie IL na kod maszynowy w momencie pierwszego wywołania metody
• Garbage Collection — automatyczne zwalnianie pamięci po obiektach, których już nie używasz
• Bezpieczeństwo typów w runtime — sprawdzanie rzutowań, granic tablic itp.
• Obsługa wyjątków — mechanizm try/catch/finally

Twój .dll (IL)
      ↓
   CLR ładuje
      ↓
 JIT kompiluje metodę Main() → kod maszynowy → CPU wykonuje
      ↓
 Wywołujesz inne metody → JIT kompiluje każdą przy pierwszym wywołaniu

JIT to powód, dla którego pierwszy start aplikacji .NET bywa wolniejszy — kompiluje kod “na gorąco”. W .NET istnieje też AOT (Ahead-of-Time compilation), który kompiluje wszystko przed uruchomieniem — używany m.in. w Blazor WebAssembly.

Warstwa 3 — Runtime: błędy, których kompilator nie widzi

Niektórych błędów Roslyn nie jest w stanie wykryć na etapie kompilacji — bo zależą od danych wejściowych, stanu obiektu lub zewnętrznych zasobów.

string? input = Console.ReadLine();  // użytkownik wpisze cokolwiek
int liczba = int.Parse(input);       // kompilator: OK. Runtime: FormatException, jeśli user wpisze "abc"

string[] imiona = { "Anna", "Piotr" };
Console.WriteLine(imiona[5]);  // kompilator: OK. Runtime: IndexOutOfRangeException

string? tekst = null;
Console.WriteLine(tekst.Length);  // kompilator: OK (z ostrzeżeniem). Runtime: NullReferenceException

Błędy runtime to wyjątki (Exception). Jeśli ich nie obsłużysz (try/catch), program się wysypie. CLR wyświetli stack trace — listę wywołań metod prowadzącą do błędu — i to jest pierwsze miejsce, które czytasz gdy coś pójdzie nie tak.

Ten podział na warstwy to dokładnie to, co szerzej opisujemy w artykule Czym jest .NET? CLR, BCL i różnice wersji. A jeśli zamiast mechaniki chcesz zobaczyć, jak to samo myślenie warstwami przekłada się na strukturę Twojego własnego kodu, zobacz mental model programisty C#.

Stack i Heap — gdzie żyją zmienne

Dwa miejsca w pamięci, w których CLR przechowuje dane:

Stack (stos) — szybka pamięć, używana dla:

• Lokalnych zmiennych typów wartościowych (int, bool, double, struct)
• Parametrów metod
• Adresów powrotu z metod

Zmienne na stosie istnieją tylko podczas wykonania danej metody. Kiedy metoda kończy działanie — stos jest “zwijany” i ich pamięć jest zwalniana automatycznie.

Heap (sterta) — wolniejsza pamięć, używana dla:

• Obiektów (class, string, tablice)
• Pamięci zarządzanej przez Garbage Collector

void PrzykladMetody()
{
    int x = 10;              // Stack — żyje do końca metody
    string tekst = "Hello";  // tekst (referencja) na Stack, ale obiekt string na Heap
    
    var produkt = new Product { Id = 1 };  // referencja na Stack, obiekt Product na Heap
    
}  // ← koniec metody: x znika ze stosu, referencje znikają
   //   Garbage Collector w swoim czasie zwolni obiekty na Heap

Garbage Collector działa w tle i zwalnia pamięć obiektów, do których nie ma już żadnych referencji. Dlatego w C# rzadko martwisz się o ręczne zwalnianie pamięci — poza zasobami niezarządzanymi (pliki, połączenia sieciowe), gdzie używasz IDisposable i using.

Jak czytać błędy — praktycznie

Błąd kompilatora

error CS0029: Cannot implicitly convert type 'int' to 'string'

Format: error CS[numer]: opis. Numer kodu błędu możesz wkleić w Google lub docs.microsoft.com — każdy ma swoją stronę z wyjaśnieniem i przykładem.

Błędy kompilatora zawierają też plik i numer linii:

Program.cs(12,15): error CS0029: Cannot implicitly convert type 'int' to 'string'

Czytaj od prawej do lewej: najpierw co (CS0029), potem gdzie (Program.cs linia 12, kolumna 15).

Wyjątek runtime — stack trace

Unhandled exception. System.NullReferenceException: Object reference not set to an instance of an object.
   at ShopService.GetTotal() in ShopService.cs:line 45
   at Program.Main() in Program.cs:line 12

Czytaj od góry: typ wyjątku (NullReferenceException), potem pierwsze wpisy w stack trace — to miejsce, gdzie błąd faktycznie wystąpił. Szukasz pierwszej linii, która wskazuje na Twój kod (nie biblioteki systemowe).

Kompilacja inkrementalna i hot reload

Nie musisz kompilować całego projektu za każdym razem. dotnet build używa kompilacji inkrementalnej — rebuiltuje tylko te pliki .cs, które zmieniły się od ostatniej kompilacji.

dotnet watch run (hot reload) idzie dalej: śledzi zmiany plików i przeładowuje kod bez restartu procesu. Działa dla wielu typów zmian (ciała metod, nowe metody), nie działa dla zmian strukturalnych (nowe typy, zmiany sygnatur).

Pułapki, które wynikają z tego modelu

Pułapka #1: Mylenie błędu kompilacji z wyjątkiem runtime

Oba wyglądają podobnie — czerwony tekst w konsoli — ale to zupełnie różne sytuacje. Błąd CS**** oznacza, że program w ogóle się nie zbudował — nie ma pliku wykonywalnego, nie masz czego uruchomić. Wyjątek runtime (NullReferenceException, IndexOutOfRangeException) oznacza, że program zbudował się poprawnie i zaczął działać, a problem pojawił się dopiero podczas wykonania — często zależnie od konkretnych danych wejściowych. Jeśli szukasz błędu kompilacji w stack trace albo wyjątku runtime w komunikatach kompilatora, tracisz czas na złym etapie.

Pułapka #2: Typ wartościowy przekazany do metody nie zmienia się na zewnątrz

void Zwieksz(int liczba)
{
    liczba++; // zmienia lokalną KOPIĘ, nie oryginał
}

int x = 5;
Zwieksz(x);
Console.WriteLine(x); // wciąż 5, nie 6

int to typ wartościowy — kiedy przekazujesz go do metody, metoda dostaje kopię na swoim własnym stosie, nie referencję do oryginału. Zmiana liczba wewnątrz Zwieksz nie ma żadnego wpływu na x w metodzie wywołującej. To zaskakuje początkujących przyzwyczajonych do myślenia, że przekazanie zmiennej do metody zawsze pozwala ją zmienić.

Pułapka #3: Zmiana sygnatury metody podczas hot reload

dotnet watch run przeładowuje ciała metod na bieżąco, ale nie radzi sobie ze zmianami strukturalnymi — nową metodą, nowym polem, zmienioną sygnaturą. Jeśli dodasz parametr do metody i hot reload nagle przestaje działać albo zgłasza dziwny błąd, to nie jest bug w Twoim kodzie — to ograniczenie mechanizmu. Zatrzymaj dotnet watch i uruchom dotnet run od nowa.

Podsumowanie

Kiedy pojawia się błąd:

1. Błąd CS**** → szukaj problemu w kodzie źródłowym — typ, brakująca zmienna, błąd składni
2. Wyjątek runtime → czytaj stack trace, znajdź pierwszą linię ze swoim kodem, sprawdź wartości zmiennych w debuggerze

Rozumienie tych trzech warstw sprawia, że każdy komunikat o błędzie przestaje być tajemniczy — wiesz, które narzędzie go zgłosiło i co sprawdza.

Następny post: Sposób, w jaki komputer wykonuje program — jak CPU, RAM i system operacyjny współpracują przy uruchamianiu kodu, i dlaczego instrukcje wykonują się w określonej kolejności.