Wykonywanie oparte na plikach C# w .NET 10

Uruchamianie Jednego Pliku C

[0:40 - 1:48] Tim starts in VS Code with an empty folder. Bez rozwiazania, bez pliku projektu, bez szablonu. Tworzy pojedynczy plik o nazwie demo.cs z jedną linią kodu:

Console.WriteLine("Hello World");

Console.WriteLine("Hello World");

Aby go wykonac:

dotnet run file demo.cs

dotnet run file demo.cs

To jest pelny ciag roboczy. Polecenie dotnet run file kompiluje i wykonuje plik .cs w jednym kroku. Nie ma generowanego pośredniego .csproj, ani folderów bin czy obj. Model mentalny jest blizszy skryptowaniu niz tradycyjnemu rozwojowi C#: napisz plik, uruchom go, zobacz rezultat.

Tim porownuje to bezposrednio do Pythona i JavaScript, gdzie jednoplikowe wykonanie zawsze bylo domyslem. .NET 10 wprowadza C# na to samo terytorium, zachowujac bezpieczenstwo typu i wydajnosc, ktore czynia C# atrakcyjnym w pierwszej kolejnosci.

Argumenty Wiersza Polecen i Implicit Usings

[1:48 - 3:26] Tablica args jest dostępna automatycznie, tak jak by to było w standardowym Program.cs z instrukcjami najwyższego poziomu. Tim modyfikuje plik, by akceptowal argument nazwy:

Console.WriteLine($"Hello {args[0]}");

Console.WriteLine($"Hello {args[0]}");

Uruchamianie go z argumentem:

dotnet run file demo.cs Tim

dotnet run file demo.cs Tim

To wypisuje "Hello Tim". Tim zauważa, że Console.WriteLine działa bez instrukcji using System;, ponieważ wykonanie opiera się na plikach, które domyślnie zawierają domyślne użycia. To się dzieje dokładnie tak samo jak w wprowadzeniu stwierdzen najwyzszego poziomu w C# 9, teraz rozszerzonym na samodzielne pliki.

Szerszy wzorzec, jaki Microsoft podąża, to eliminowanie zbędnych formalności w C# z każdą nową wersją. Globalne użycia, instrukcje najwyższego poziomu, a teraz samodzielne pliki .cs to kroki w kierunku umożliwienia C# wykonywania szybkich zadań, które wcześniej wymagały skryptów Python lub bash.

Dodawanie Wejscia Uzytkownika

[3:26 - 5:43] Tim zastepuje podejscie argumentowe interaktywnym wejsciem, aby zademonstrowac, ze wykonanie oparte na plikach wspiera pelny zakres wzorcow aplikacji konsolowej:

Console.Write("What is your name? ");
string name = Console.ReadLine();
Console.WriteLine($"Hello {name}");

Console.Write("What is your name? ");
string name = Console.ReadLine();
Console.WriteLine($"Hello {name}");

Uruchamianie tego wyprowadza na wejscie, odczytuje odpowiedz i wypisuje pozdrowienie. Standardowe wprowadzanie-wyprowadzanie dziala identycznie jak w pelnym projekcie.

Jedno ograniczenie, które wskazuje Tim: ten tryb jest ściśle jednoplikowy. Nie można mieć dwóch plików .cs odwołujących się do siebie nawzajem. Jesli twoj kod rosnie do punktu, w ktorym potrzebujesz wielu plikow, czas przeksztalcic to w projekt (omowione pozniej w filmie).

Wprowadzanie Pakietow NuGet

[5:43 - 7:49] To jest miejsce, gdzie podejscie jednoplikowe staje sie naprawde uzyteczne dla skryptow. Można odwoływać się do pakietów NuGet bezpośrednio wewnątrz pliku .cs za pomocą dyrektywy #r na górze:

#r "nuget:Spectre.Console, 0.54.0"
using Spectre.Console;

Console.Write("What is your name? ");
string name = Console.ReadLine();
AnsiConsole.MarkupLine($"Hello [red]{name}[/]");

#r "nuget:Spectre.Console, 0.54.0"
using Spectre.Console;

Console.Write("What is your name? ");
string name = Console.ReadLine();
AnsiConsole.MarkupLine($"Hello [red]{name}[/]");

Składnia #r "nuget:..." informuje środek czasu wykonywania, że należy pobrać i odwołać się do określonego pakietu przed kompilacją. Tim uzywa Spectre.Console do kolorowania wyniku, zamieniajac tekst pozdrowniania na czerwony.

Brak polecenia dotnet add package, brak edycji .csproj, brak kroku przywracania. Odwołanie do pakietu znajduje się w samym pliku źródłowym. Dla skryptow, ktore potrzebuja klienta HTTP, serializatora JSON lub biblioteki formatowania, to eliminuje koniecznosc tworzenia projektu tylko po to, aby pobrac jedna zaleznosc.

Publikowanie do Natywnego Wykonywalnego

[7:49 - 8:59] Gdy chcesz rozpowszechniac skrypt oparty na plikach jako samodzielny plik binarny, komenda publish to obsluguje:

dotnet publish file demo.cs

dotnet publish file demo.cs

Tworzy to wykonywalny program w folderze artifacts. Skompilowany plik binarny zawiera wszystko, co jest potrzebne do uruchomienia, bez potrzeby SDK .NET na maszynie docelowej. Tim zauwaza, ze budowa oparta na plikach uzywa Native AOT domyslnie, co oznacza, ze wynik jest jednym, samodzielnym plikiem binarnym z szybkim czasem startu.

Jeśli Native AOT powoduje problemy z kompatybilnością z określoną biblioteką, można go wyłączyć, dodając dyrektywę właściwości na górze pliku (podobnie jak działa #r dla pakietów). Dla wiekszosci przypadkow uzycia skryptow, jednakze, AOT jest wlasciwym domyslem.

Przekształcanie w Pełny Projekt

[8:59 - 10:45] Luka awaryjna, gdy skrypt przerasta format jednoplikowy, to polecenie convert:

dotnet project convert file demo.cs

dotnet project convert file demo.cs

To generuje plik .csproj, który zawiera referencje pakietu NuGet z dyrektyw #r i przenosi kod do standardowej struktury projektu. Od tej chwili, mozesz dodawac wiele plikow, konfigurowac ustawienia budowy i uzywac pelnego systemu projektu .NET.

Tim przedstawia to jako naturalną progresję: rozpocznij od pojedynczego pliku do szybkiego eksperymentowania, a gdy zasieg expanduje, przeksztalc to w projekt bez przepisania czegokolwiek. Dyrektywy #r tłumaczą się płynnie na wpisy <PackageReference> w generowanym .csproj.

Native AOT i Uwagi Platformowe

[10:45 - 12:42] Domyslnie, wykonanie na podstawie plikow kompiluje z Native AOT, co daje najszybsze mozliwe czasy startu. Tim zwraca uwage, ze to jest idealne dla narzedzi CLI i skryptow, w ktorych zimne starty maja znaczenie. Jesli biblioteka nie jest zgodna z AOT, funkcja moze zostac wylaczona przy pomocy dyrektywy na poziomie pliku.

Na Linuxie i macOS można także dodać hashbang (#!/usr/bin/dotnet run file) na górze pliku .cs, co sprawia, że jest on bezpośrednio wykonywalny z powłoki bez wpisywania prefiksu dotnet run file. To wprowadza C# w pelni na terytorium skryptowania obok bash, Python i Ruby.

Podsumowanie: C# jako Język Skryptowy

[12:42 - 13:05] Funkcja, ktora Tim podkresla jako najwazniejsza, jest eliminacja nadmiaru projektu dla malych zadania. Aplikacje konsolowe zawsze byly wybierane do szybkich eksperymentow, skryptow automatyzacji i jednorazowych narzedzi. Wykonanie na bazie plikow usuwa ceremonie, ktora sprawiala, ze te odczuwaly sie ciezsze, niz musiały byc, zachowujac kazda przewage (bezpieczenstwo typu, wydajnosc, ekosystem NuGet), ktora czyni C# wartego wyboru zamiast jezeli skryptowego.

Wnioski

[13:05 - 13:36] Podsumowując: wykonywanie oparte na plikach .NET 10 pozwala uruchomić pojedynczy plik .cs z dotnet run file, odwoływać się do pakietów NuGet za pomocą dyrektyw #r, publikować do natywnej binarnej z dotnet publish file i konwertować na pełny projekt z dotnet project convert file, gdy przerośnie się jednoplikowy format. Domyślnie Native AOT jest włączony, a użytkownicy Linux/macOS otrzymują wsparcie dla hashbang do wykonywania na poziomie powłoki.

Jeśli obecnie używa się aplikacji konsolowej do prototypowania lub automatyzacji, warto spróbować tego jako lżejszej alternatywy.

Przykład porady: Jeśli tworzysz aplikacje konsolowe tylko po to, aby przetestować pakiet NuGet lub debugować wywołanie API, spróbuj zamiast tego wykonywania plikowego. Utwórz plik .cs, dodaj #r "nuget:PackageName, Version" na górze, napisz swój kod testowy i uruchom go za pomocą dotnet run file. Gdy skończysz, usuń plik. Nie jest wymagane czyszczenie projektu.

Obejrzyj pełne wideo na jego kanale YouTube Channel i zdobądź więcej informacji na temat nowoczesnych workflow rozwoju C#.