Jak działa program C# — od kodu źródłowego 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.

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).

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.