Czego się dziś nauczysz

Problem: procesor nie zna C#

Kod, który piszesz, jest zrozumiały dla człowieka. Procesor rozumie coś zupełnie innego — kod maszynowy, czyli ciąg liczb oznaczających elementarne operacje: „weź liczbę z pamięci”, „dodaj”, „skocz do innego miejsca”. Ktoś musi jedno przetłumaczyć na drugie. Robi to kompilator.

Kompilator a interpreter

To dwa różne podejścia do tego samego zadania.

Języki takie jak Python czy JavaScript są tradycyjnie interpretowane. C# jest kompilowany — i to właśnie dlatego Visual Studio potrafi podkreślić błąd na czerwono, zanim jeszcze uruchomisz program.

Dwa etapy zamiast jednego

W C# tłumaczenie nie odbywa się jednym skokiem. Dzieje się w dwóch krokach, w różnych momentach.

  Program.cs                    plik .dll                     kod maszynowy
  (kod w C#)                    (kod pośredni IL)             (rozumie procesor)
      │                              │                              │
      │   ETAP 1: kompilator         │   ETAP 2: kompilator JIT     │
      │   Roslyn                     │   w środowisku .NET          │
      └─────────────────────────────►└─────────────────────────────►
      gdy klikasz „Zbuduj"           gdy program działa

Etap 1 — kompilator Roslyn: C# → kod pośredni

Gdy budujesz projekt, do pracy zabiera się Roslyn — kompilator języka C#. Sprawdza kod pod względem poprawności i tłumaczy go na kod pośredni, nazywany IL (ang. Intermediate Language).

IL to język pośredni między C# a kodem maszynowym. Nie jest przeznaczony dla człowieka, ale też nie jest jeszcze zrozumiały dla procesora. Ważne: IL nie zależy od tego, na jakim procesorze i systemie ostatecznie uruchomisz program.

Etap 2 — kompilator JIT: kod pośredni → kod maszynowy

Gdy uruchamiasz program, wkracza środowisko uruchomieniowe .NET. Zawiera ono kompilator JIT (ang. Just-In-Time — „w samą porę”), który tłumaczy IL na kod maszynowy dopiero w trakcie działania programu i dokładnie dla tego procesora, na którym program właśnie działa.

Dlaczego C# nazywa się językiem hybrydowym

Bo łączy oba podejścia: kompiluje się jak język kompilowany (błędy wychodzą przed uruchomieniem) i tłumaczy się w trakcie działania jak język interpretowany (dopasowanie do konkretnego sprzętu). Stąd też wzięło się określenie „zarządzany” (ang. managed) — twój kod nie działa bezpośrednio na procesorze, tylko pod opieką środowiska .NET, które pilnuje pamięci i bezpieczeństwa typów.

Co naprawdę powstaje na dysku

Zbuduj projekt z poprzedniej lekcji i zajrzyj do folderu bin\Debug\. Znajdziesz tam kilka plików — warto wiedzieć, który jest który.

PierwszyProgram.dll                 ← TUTAJ jest twój kod (w postaci IL)
PierwszyProgram.exe                 ← mały program uruchamiający
PierwszyProgram.pdb                 ← informacje dla debugera
PierwszyProgram.runtimeconfig.json  ← która wersja .NET ma to uruchomić
PierwszyProgram.deps.json           ← lista zależności projektu

Omówienie

Debug czy Release?

Konfigurację zmienia się na pasku narzędzi Visual Studio, w rozwijanym polu obok przycisku uruchamiania. Na czas nauki zostaw Debug — potrzebujesz dokładnych komunikatów o błędach bardziej niż szybkości.

To samo z wiersza poleceń

Visual Studio wykonuje kompilację za ciebie, ale wszystko to samo można zrobić poleceniem dotnet. Warto je znać: na egzaminie zawodowym bywa szybsze, a na Linuksie często jest jedyną drogą.

dotnet new console -o MojProgram   # utwórz nowy projekt w folderze MojProgram
cd MojProgram                      # wejdź do tego folderu
dotnet build                       # skompiluj (C# → IL)
dotnet run                         # skompiluj i od razu uruchom
dotnet clean                       # usuń wyniki kompilacji

Plik projektu

Obok Program.cs leży plik z rozszerzeniem .csproj. To zwykły plik XML z ustawieniami projektu:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
</Project>

Jak czytać komunikaty kompilatora

Komunikat kompilatora ma zawsze ten sam układ. Warto raz nauczyć się go czytać — potem oszczędzi ci to godziny.

Program.cs(7,42): error CS1002: Oczekiwano ;
     │        │ │         │
     │        │ │         └── treść: co jest nie tak
     │        │ └── kod błędu — wpisz go w wyszukiwarkę, to działa
     │        └── wiersz 7, znak 42
     └── plik, w którym wystąpił problem

Błąd czy ostrzeżenie?

Najczęstsze błędy na początku

Zadania

using System

namespace MojaAplikacja
{
    class Program
    {
        static void Main(string[] args)
        {
            string imie = "Jan"
            Console.Writeline("Cześć " + imie)
        }
    }

using System;                                  // 1. dodany średnik

namespace MojaAplikacja
{
    class Program
    {
        static void Main(string[] args)
        {
            string imie = "Jan";                      // 2. dodany średnik
            Console.WriteLine("Cześć " + imie);       // 3. WriteLine + średnik
        }
    }
}                                                  // 4. dodana klamra zamykająca

dotnet new console -o Test
cd Test
notepad Program.cs        # zmień tekst i zapisz
dotnet build
dotnet run

dotnet build -c Debug
dotnet build -c Release

Co trzeba zapamiętać

• Kompilator tłumaczy cały program przed uruchomieniem, interpreter — linia po linii w trakcie działania.
• Kod C# przechodzi przez dwa etapy: Roslyn tłumaczy go na kod pośredni IL, a JIT — z IL na kod maszynowy.
• IL nie zależy od systemu ani procesora — to dzięki niemu jeden plik działa wszędzie.
• JIT tłumaczy każdą metodę raz, przy jej pierwszym wywołaniu, i dopasowuje kod do procesora, na którym program działa.
• Twój program mieszka w pliku .dll. Plik .exe jest tylko programem uruchamiającym.
• Debug — na czas pisania, Release — gdy program jest gotowy.
• Komunikat błędu podaje plik, wiersz, kod (np. CS1002) i opis. Poprawiaj zawsze od pierwszego błędu.
• Ostrzeżeń nie wolno ignorować — bardzo często zapowiadają realny problem.