Wdrażanie aplikacji ASP.NET Core — publikacja i środowiska

Gotowa aplikacja uruchamiana z Visual Studio (tryb Debug) to nie to samo, co aplikacja gotowa do udostępnienia prawdziwym użytkownikom w internecie. Ta lekcja pokazuje, jak przygotować aplikację ASP.NET Core do wdrożenia (publish), czym różnią się środowiska Development/Production, i jak skonfigurować bezpieczne przechowywanie sekretów (haseł do bazy danych) — odpowiednik lekcji o publikacji APK/AAB z działu MAUI, tylko dla aplikacji webowej.

Wdrażanie PARY Angular + ASP.NET Core. Skoro Twoja aplikacja składa się z DWÓCH projektów (frontend Angular, backend ASP.NET Core), wdrożenie wymaga zbudowania OBU: ng build kompiluje i optymalizuje projekt Angular do statycznych plików HTML/CSS/JS (folder dist/), a dotnet publish kompiluje backend C#. W szablonie "ASP.NET Core with Angular" z lekcji 3, backend jest skonfigurowany tak, by przy publikacji AUTOMATYCZNIE zbudować i dołączyć pliki frontendu (przez app.MapFallbackToFile("/index.html"), poznane w lekcji 3) — efekt: JEDEN, gotowy do wdrożenia zestaw plików, choć nadal warto rozumieć, co dzieje się z każdą częścią osobno.

Środowiska (Environments). ASP.NET Core rozróżnia środowiska uruchomieniowe — najczęściej Development (praca lokalna, szczegółowe komunikaty błędów ułatwiające debugowanie) i Production (środowisko "na żywo", gdzie szczegóły błędów są UKRYTE przed użytkownikiem ze względów bezpieczeństwa). Zmienna środowiskowa ASPNETCORE_ENVIRONMENT decyduje, które środowisko jest aktywne. W kodzie: if (!app.Environment.IsDevelopment()) { app.UseExceptionHandler("/Error"); } — pokazuje przyjazną stronę błędu ZAMIAST pełnego stosu wywołań (stack trace) na produkcji, gdzie ujawnienie szczegółów wewnętrznej struktury kodu byłoby ryzykiem bezpieczeństwa.

Publikacja aplikacji. Polecenie dotnet publish -c Release -o ./publikacja (albo odpowiadająca opcja "Publikuj" w Visual Studio) kompiluje aplikację w trybie Release (zoptymalizowanym, bez informacji debugowania) i umieszcza WSZYSTKIE potrzebne pliki (skompilowany kod, zależności, pliki statyczne z wwwroot) w jednym folderze wynikowym, gotowym do skopiowania na serwer.

Serwer Kestrel a odwrotne proxy (reverse proxy). Wbudowany serwer Kestrel (używany podczas developmentu) MOŻE obsługiwać ruch produkcyjny bezpośrednio, ale standardową praktyką jest postawienie PRZED nim dodatkowego serwera — Nginx (na Linux) albo IIS (na Windows) — działającego jako odwrotne proxy: przyjmuje ruch z internetu, obsługuje HTTPS/certyfikaty, i przekazuje żądania do Kestrela działającego "za kulisami". To dodaje warstwę bezpieczeństwa i elastyczności (np. można postawić WIELE aplikacji za jednym serwerem proxy, każdą pod innym adresem).

Bezpieczne przechowywanie sekretów. Connection string do bazy produkcyjnej, hasła, klucze API — te dane NIGDY nie powinny trafić do repozytorium Git razem z kodem źródłowym (dokładnie ta sama zasada co przy kluczu podpisującym APK w dziale MAUI). Podczas developmentu służy do tego User Secrets (dotnet user-secrets set "Klucz" "wartosc" — zapisuje dane POZA folderem projektu, na dysku dewelopera). Na serwerze produkcyjnym typowo używa się zmiennych środowiskowych systemu operacyjnego albo dedykowanych usług zarządzania sekretami (np. Azure Key Vault).

Docker jako alternatywa wdrożenia (narzędzie konteneryzacji, przydatne też poza samym .NET) — zamiast ręcznie kopiować pliki na serwer, aplikację ASP.NET Core można "zapakować" w kontener Docker (przez Dockerfile, jak we wstępnym przykładzie z lekcji o narzędziach) i uruchomić IDENTYCZNIE na dowolnym serwerze obsługującym Dockera — eliminuje to problem "u mnie działało" przy przenoszeniu aplikacji między środowiskami.