Masz projekt .NET, który działa na Windowsie, ale wymaga linuksowego narzędzia albo środowiska zgodnego z produkcją? WSL uruchamia dystrybucję Linuksa obok Windowsa, zwykle bez osobnej maszyny wirtualnej do konfigurowania, choć wybór systemu plików potrafi zmienić szybkość pracy bardziej niż sama dystrybucja.
WSL najlepiej działa, gdy narzędzia i pliki projektu są po tej samej stronie
- Instalacja: w PowerShellu uruchom
wsl --install, a potem wybierz dystrybucję. - Domyślny wybór: WSL 2 zapewnia pełne jądro Linuksa i zgodność z większą liczbą narzędzi.
- Wydajność: projekty budowane linuksowymi narzędziami trzymaj w katalogu Linuksa, na przykład
~/projects. - Wyjątek: WSL 1 może pasować do pracy na plikach Windows, gdy linuksowe narzędzia muszą często je odczytywać.
- Dla kontenerów: WSL zawiera obecnie własne narzędzie
wslc, dostępne w WSL w wersji 2.9.3 lub nowszej.
WSL 2 uruchamia prawdziwe jądro Linuksa w zarządzanej maszynie wirtualnej
Otwierasz Terminal, wpisujesz wsl i dostajesz powłokę Bash, ale pod spodem działa więcej niż emulator poleceń. WSL 2 korzysta z linuksowego jądra wewnątrz lekkiej maszyny wirtualnej zarządzanej przez Windows, więc może obsłużyć narzędzia wymagające systemowych funkcji Linuksa.
To wyjaśnia, dlaczego WSL 2 nadaje się do uruchamiania wielu linuksowych narzędzi, usług i aplikacji graficznych. Nie oznacza jednak, że otrzymujesz osobny komputer z pełną, niezależną konfiguracją sieci i sprzętu. Microsoft opisuje tę architekturę jako zarządzaną maszynę wirtualną, która startuje i integruje się z Windowsem bez ręcznego konfigurowania VM.
WSL 1 działa inaczej: tłumaczy wywołania systemowe Linuksa, zamiast uruchamiać własne jądro. W praktyce WSL 2 jest rozsądnym wyborem dla nowych projektów, a do WSL 1 wraca się w określonych przypadkach, zwłaszcza gdy przepływ pracy zależy od częstego dostępu do plików Windows.
Instalacja zajmuje jedno polecenie, a dystrybucję możesz wybrać później
Jeśli zaczynasz od zera, otwórz PowerShell i wpisz wsl --install. Domyślnie instalowany jest Ubuntu; po ponownym uruchomieniu systemu uruchom dystrybucję z menu Start i utwórz linuksową nazwę użytkownika oraz hasło.
Gdy wolisz inną bazę, najpierw sprawdź dostępne opcje przez wsl --list --online, a potem wskaż nazwę w poleceniu, na przykład wsl --install -d Debian. Ubuntu ma dużo poradników i pakietów dla typowych narzędzi deweloperskich, Debian może odpowiadać osobom szukającym oszczędniejszej instalacji. Dystrybucje mogą różnić się wersjami pakietów, więc dopasuj je do środowiska docelowego.
Po instalacji sprawdź stan poleceniem wsl --list --verbose. Zobaczysz tam dystrybucje i używaną wersję WSL; jeśli trzeba, ustaw domyślną komendą wsl --set-default-version 2. Wymagania dla instalacji WSL poleceniem wsl --install obejmują Windows 11 lub Windows 10 w wersji 2004 i nowszej, z kompilacją 19041 lub nowszą.
Projekt .NET trzymaj tam, gdzie uruchamiasz jego narzędzia
Najczęstsza pułapka wychodzi dopiero przy dotnet restore, instalacji zależności albo kompilacji dużego repozytorium. Gdy projekt leży na dysku Windows pod ścieżką widoczną w Linuksie jako /mnt/c/..., operacje plikowe przekraczają granicę między systemami i mogą zwolnić.
Microsoft Learn w dokumencie „Working across file systems” zaleca przechowywanie plików w systemie, którego narzędzia ich używają. Przy pracy w WSL trzymaj repozytorium na przykład w ~/projects/aplikacja, a do edycji użyj Visual Studio Code z rozszerzeniem WSL. Edytor działa w Windowsie, ale terminal, rozszerzenia i polecenia projektu mogą pracować po stronie Linuksa.
| Sytuacja | Co się dzieje | Co zrobić |
|---|---|---|
Budujesz w WSL, a projekt leży w /mnt/c | Operacje na wielu plikach przechodzą przez granicę systemów. | Przenieś lub sklonuj repozytorium do katalogu domowego Linuksa. |
| Budujesz natywnymi narzędziami Windows | Projekt w katalogu Windows jest dostępny bez tej granicy dla procesu Windows. | Trzymaj repozytorium na dysku Windows. |
| Potrzebujesz otworzyć plik linuksowy w Eksploratorze | Windows może uzyskać dostęp do katalogów dystrybucji przez ścieżkę sieciową WSL. | Użyj \\wsl.localhost\Ubuntu\home\... do zwykłego dostępu, nie jako lokalizacji dla intensywnych operacji Windows. |
Ta sama zasada dotyczy Git, Node.js, Pythona i narzędzi kontenerowych: nie mieszaj lokalizacji plików i środowiska wykonawczego bez powodu. Uważam, że właśnie ten wybór oszczędza najwięcej niepotrzebnego diagnozowania „wolnego WSL”.
Wybierz WSL 1 tylko wtedy, gdy przepływ pracy tego wymaga
Dwie wersje WSL rozwiązują podobny problem, ale różnią się mechanizmem działania. Dokument Microsoft Learn „Comparing WSL Versions” wskazuje pełną zgodność wywołań systemowych i obsługę systemd po stronie WSL 2, a lepszą wydajność pracy między systemami plików po stronie WSL 1.
Prosta reguła wyboru: jeśli większość pracy wykonujesz linuksowymi narzędziami i możesz trzymać repozytorium w Linuksie, wybierz WSL 2. Jeśli pliki muszą pozostać na dysku Windows i narzędzia Linuksa często wykonują na nich operacje, sprawdź WSL 1 dla tej dystrybucji. Wersję można sprawdzić i zmienić poleceniami wsl --list --verbose oraz wsl --set-version Ubuntu 1.
Na komputerze z Windows 11 w wersji 22H2 lub nowszej WSL 2 obsługuje też tryb sieci lustrzanej, który można ustawić w pliku .wslconfig. Przy problemach z dostępem do lokalnej usługi albo VPN sprawdź najpierw tryb sieci, zamiast zakładać, że aplikacja w Linuksie zawsze widzi sieć dokładnie tak jak proces Windows.
Kontenery i aplikacje graficzne rozszerzają WSL, ale nie usuwają granic
WSL sprawdza się przy pracy z usługami linuksowymi, narzędziami CLI i testowaniem aplikacji w środowisku zbliżonym do serwera. Aplikację Windows, taką jak Visual Studio Code, możesz połączyć z dystrybucją przez WSL; uruchomione w niej usługi często są dostępne z poziomu Windows przez localhost.
W aktualnej linii WSL dostępne jest również wslc, wbudowane narzędzie do tworzenia i uruchamiania kontenerów Linuksa. Wymaga WSL w wersji 2.9.3 lub nowszej; sprawdź wersję poleceniem wsl --version, a w razie potrzeby zaktualizuj ją przez wsl --update. Jeśli projekt zespołu opiera się na Docker Desktop lub konkretnym zestawie narzędzi, trzymaj się zgodnego z nim środowiska zamiast zmieniać je wyłącznie dlatego, że istnieje nowa opcja.
Przy pracy z AI WSL może też udostępnić linuksowe narzędzia do obliczeń GPU, ale wymaga to zgodnego sprzętu i sterownika Windows obsługującego tę ścieżkę. Dla typowego projektu .NET zacząłbym od dystrybucji, właściwego położenia repozytorium i integracji z edytorem; dodatkowe funkcje mają sens dopiero wtedy, gdy projekt ich potrzebuje.
Najmniej problemów daje jeden system plików na projekt
Gdy kompilacja jest wolna, sprawdź najpierw, czy kod leży w /mnt/c, czy w linuksowym katalogu domowym. Gdy aplikacja nie widzi usługi, przyjrzyj się trybowi sieci i temu, po której stronie działa proces. WSL daje wygodny most między Windowsem a Linuksem, ale spokojna praca zaczyna się od decyzji, która strona będzie głównym środowiskiem danego projektu.
