Jak publikować i wdrażać użytkowe narzędzie WPF .NET

Wydawanie z Visual Studio

[1:03 - 1:25] Tim zaczyna od kliknięcia prawym przyciskiem myszy na projekt w Visual Studio i wybrania Publikuj. Kreator przedstawia kilka celów (Azure, Docker, ClickOnce), ale pomija wszystkie z nich i wybiera Folder. Dla osobistego narzędzia, które działa na Twoich własnych komputerach, publikacja do folderu to najkrótsza droga: produkuje pliki, które możesz kopiować gdziekolwiek ich potrzebujesz bez infrastruktury wdrożeń.

Po wybraniu celu folderu, Tim przechodzi bezpośrednio do strony ustawień zamiast uruchamiania publikacji natychmiast. Domyślne potrzeby dostosowania, zanim rezultat będzie odpowiadał jego oczekiwaniom.

Uzależnione od frameworku vs. Samodzielne

[1:25 - 2:32] Pierwsze ustawienie to tryb wdrożenia. Budowanie zależne od frameworku zakłada, że .NET SDK lub uruchomienie jest już zainstalowane na maszynie docelowej. Rezultat jest mały, około 200 kilobajtów dla tej aplikacji, ponieważ opiera się na współdzielonym środowisku runtime, które istnieje na twoim systemie.

Budowanie samodzielne pakuje całe środowisko .NET do rezultatu. To czyni paczkę przenośną na maszyny bez zainstalowanego .NET, ale rozmiar wzrasta do około 140 megabajtów. Tim wybiera budowanie zależne od frameworku, ponieważ każda maszyna, której używa, już ma zainstalowane .NET. Jeśli rozprowadzacie narzędzie do kolegów lub klientów, którzy mogą nie mieć uruchomienia, samodzielne jest bezpieczniejszą opcją, ale dla osobistych narzędzi ta wymiana rzadko ma sens.

Dlaczego WPF a nie MAUI

[2:50 - 4:10] Tim odnosi się do opinii, które otrzymał na temat użycia WPF zamiast MAUI dla tego projektu. Jego rozumowanie jest praktyczne, a nie ideologiczne. Przeglądarka obrazów musi działać tylko na Windows. Wprowadzenie MAUI i jego warstwy międzyplatformowej wprowadza narzut bez przynoszenia żadnych korzyści dla narzędzia jednoplatformatowego.

Poza argumentem architektonicznym, jest także kąt konserwacji. Pierwotny kod źródłowy Tima przetrwał około siedem lat na czterech lub pięciu maszynach z minimalnymi zmianami. Jedynymi aktualizacjami były aktualizacje frameworka (z .NET Framework do .NET 8, następnie do .NET 10). Jeśli narzędzie byłoby zbudowane na frameworku, który wymaga uwagi za każdym razem, gdy Apple lub Google wydaje aktualizację systemu, te siedem lat nieprzerwanej operacji nie byłoby możliwe. Narzędzie, które kosztuje więcej czasu na utrzymanie niż oszczędza, nie oszczędza już niczego.

Publikacja jednoplikowa i pliki PDB

[4:59 - 6:32] Po ustaleniu trybu wdrażania, Tim włącza opcję 'Produkuj pojedynczy plik' i wybiera Windows x64. Publikacja kończy się, a folder wynikowy zawiera dwa pliki: .exe i .pdb.

Drugi plik to plik bazy danych programu, a jego rola jest warta zrozumienia. Kiedy kompilujesz w trybie Release, kompilator optymalizuje i zmienia nazwy wewnętrznych symboli dla wydajności. PDB mapuje te optymalizowane nazwy z powrotem do twojej rzeczywistej bazy kodowej, pozwalając ci podłączyć debugger do działającego pliku wykonywalnego i ustawić punkty krytyczne, jakbyś pracował w trybie Debug. Dla aplikacji produkcyjnej obsługującej klientów, powinieneś przechowywać pliki PDB bezpiecznie obok każdej wersji, aby móc diagnozować problemy po wdrożeniu.

Dla narzędzia stworzonego dla siebie, Tim zaznacza, że PDB nie jest wymagane do działania aplikacji. Usuwa je dla prostoty, ale ostrzega widzów, by nie przyjęli tego przyzwyczajenia dla czegokolwiek, co zostało wysłane do użytkowników. Pojedynczy .exe działa samodzielnie bez obecności PDB.

Wartym zauważenia szczegółem jest to, że jeśli przełączysz się z budowania zależnego od frameworku na samodzielne i zachowasz włączoną opcję "Single File", rezultat nie jest już tylko jednym plikiem. Dodatkowe pliki środowiska uruchomieniowego pojawiają się obok wykonywalnego. Opcja jednoplikowa produkuje prawdziwy jednoplikowy rezultat tylko wtedy, gdy jest sparowana z budowaniem zależnym od frameworku.

Umieszczanie narzędzia na Twojej maszynie

[7:17 - 7:52] Z plikiem wykonywalnym w ręku, Tim przenosi go do stałej lokalizacji. Używa dedykowanego folderu C:\Apps\SimpleImageViewer, co jest konwencją pozwalającą oddzielić narzędzia osobiste od Program Files i łatwo je znaleźć. Plik wykonywalny z 2024 roku nadal działa identycznie na jego obecnej maszynie, co wzmacnia wcześniejszy punkt o trwałości: dobrze opisana użyteczność z prostą strukturą projektu może przetrwać zmiany sprzętowe i aktualizacje systemu operacyjnego bez modyfikacji.

Dodanie narzędzia do menu kontekstowego

[7:52 - 10:21] Ostatni krok to integracja narzędzia z menu kontekstowym Windows Explorer. Tim modyfikuje Rejestr Windows, aby dodać wpisy w dwóch lokalizacjach: jeden do kliknięcia prawym przyciskiem na folder (aby móc otworzyć katalog obrazów) i jeden do kliknięcia prawym przyciskiem w puste miejsce w katalogu (aby uruchomić przeglądarkę w bieżącym katalogu).

Każdy wpis w Rejestrze tworzy polecenie powłoki przekazujące wybraną ścieżkę jako argument wiersza poleceń do wykonywalnego. To tutaj parametr args w punkcie wejścia aplikacji otrzymuje swoją wartość.

Tim dostarcza plik .reg, ale zmienia jego nazwę na .txt przed udostępnieniem. Ten środek ostrożności jest istotny: podwójne kliknięcie pliku .reg natychmiastowo skłania do zapisania wartości w rejestrze, a uruchomienie niezaufanego pliku rejestru może spowodować poważne problemy z systemem. Jego podejście wymaga otwarcia pliku, weryfikacji ścieżek, ich aktualizacji tak, aby pasowały do twojego komputera, zmiany rozszerzenia z powrotem na .reg, a dopiero potem jego wykonania. Jeśli któraś z tych rzeczy brzmi obco, rada Tima jest bezpośrednia: nie modyfikuj rejestru.

Dla programistów zaznajomionych z rejestrem, te dwa wpisy są prostymi. Każdy tworzy nazwane polecenie powłoki pod odpowiednim kluczem, wskazując pełną ścieżkę do twojego pliku wykonywalnego z zastępczym %V lub %1, które przekazuje ścieżkę do katalogu docelowego lub pliku w czasie rzeczywistym. Może być potrzebne ponowne uruchomienie, zanim nowe pozycje menu kontekstowego się pojawią.

Zakończenie: Wdroż raz, używaj wiecznie

[10:21 - 10:30] Cały proces wdrożenia to dwa kroki: opublikuj do folderu, a następnie zarejestruj plik wykonywalny w menu kontekstowym. Bez instalatora, bez mechanizmu aktualizacji, bez usługi w chmurze. Dla narzędzia jednoprzestrzennego na Twoim własnym komputerze ta prostota jest koncepcją.

Wnioski

[10:30 - 10:40] Podsumowując: dotnet publish z ustawieniami zależnymi od frameworku i jednoplikowymi produkuje lekki plik wykonywalny, który można umieścić gdziekolwiek. Para wpisów rejestru zmienia go w akcję menu kontekstowego dostępną w dowolnym miejscu w Windows Explorer.

Lekcja, która przebiega przez całe wideo, to wstrzemięźliwość. Dopasuj swoje podejście wdrożeniowe do zakresu Twojej aplikacji. Narzędzie stworzone dla osobistego użytku nie potrzebuje tej samej infrastruktury, co produkt dostarczany tysiącom klientów, a traktowanie tego tak tylko tworzy prace związane z utrzymaniem, które niweczą czas, jaki narzędzie miało zaoszczędzić.

Przykład wskazówki: Zachowaj swoje pliki PDB, nawet dla osobistych projektów. Przechowuj je w tym samym folderze co plik wykonywalny lub w pobliskim archiwum. Jeśli narzędzie kiedykolwiek zachowa się niespodziewanie miesiące później, posiadanie PDB pozwala podłączyć Visual Studio i debugować wersję wydania bez ponownego kompilowania z kodu źródłowego.

Obejrzyj pełne wideo na jego YouTube Kanale i zyskaj więcej wglądu w wdrażanie aplikacji desktopowych .NET.