Strona główna TECH .Net WindowsForms, WPF i .Net Core

WindowsForms, WPF i .Net Core

2
WindowsForms, WPF i .Net Core

Stosunkowo niedawno Microsoft ogłosił, że zarówno WPF jak i Windows Forms otrzymają wsparcie w .Net Core 3. Postaram się w tym poście zastanowić co to tak naprawdę oznacza dla programistów, którzy rękami i nogami siedzą w desktop-ie. Sam się przecież do takich zaliczam.

.Net Core zaistniał w świadomości programistów już dosyć dawno. Wraz z nim pojawiła się możliwość tworzenia cross-platformowych aplikacji webowych i nie tylko. Aplikacje nie muszą już być hostowane na systemach Windowsowych, możemy równie dobrze hostować taką aplikację na Linuxie lub odpalić ją na systemie macOS. Wkrótce doczekamy się już wersji 3-ej, technologia ta jest na tyle dojrzała że używana jest już też z powodzeniem produkcyjnie.

Do napisania tego postu skłoniła mnie m.in. poniższa prezentacja z tegorocznego NDC – byłem bardzo ciekaw, co tak naprawdę zyskamy używając nowego .Net Core na desktopie. Przy okazji sama prezentacja jest sporym rodzynkiem – bardzo rzadko na konferencjach usłyszymy cokolwiek co tyczy się bezpośrednio desktopu.

Czy to wszystko oznacza, że możemy tworzyć w WPF i WinForms aplikacje dla Linuxa i macOS ?

No niestety nie. Zarówno Windows Forms jak i WPF są tak głęboko związane z ekosystemem Windows, że nie ma na chwilę obecną takiej możliwości. Zarówno aplikacje WPF jak i WindowsForms w połączeniu z .Net Core 3 odpalimy nadal jedynie na systemie Windows.

Co więc zyskamy ?

Z jednej strony niewiele, z drugiej być może jednak sporo. Przede wszystkim wydajność. Jak pokazuje przykład z prezentacji,  operacje na plikach działają dużo szybciej. Trzeba też wziąć pod uwagę, że na chwilę obecną stanowisko Microsoftu jest takie, że klasyczny .Net Framework będzie otrzymywał głównie maintenance a wszystko co innowacyjne trafiało będzie do Core. Czy taki stan rzeczy stanie się faktem ? Zobaczymy. Znane są przecież przypadki gdy giganci wycofują się jednak ze swoich decyzji – a jak będzie czas pokaże.

Drugą ciekawą cechą jest niezależność od zainstalowanej na maszynie wersji .Net Framwork. Możemy tworzyć aplikację, która będzie zawierać zintegrowany w sobie również sam framework .Net Core. Czy to jest dobre rozwiązanie ? Z jednej strony tak, bo nie zmuszamy użytkownika do doinstalowywania czy aktualizacji tego co już ma (lub nie ma). Z drugiej strony, pozbywamy się dobrodziejstw aktualizacji publikowanych przez Microsoft – a zawierających paczki poprawiające chociażby bezpieczeństwo. Nasza aplikacja nadal będzie działała na takiej wersji, jaką do niej spakowaliśmy a o ewentualny update będziemy musieli zadbać sami.

Co z narzędziami ?

Mamy dostępny CLI. Aplikację WPF od biedy możemy stworzyć w Visual Studio Code pisząc XAML. Z Windows Forms taka zabawa raczej odpada. Pełne wsparcie otrzymamy wraz z deisgnerami jest zapowiedziane dla Visual Studio 2019.

Czy warto się tym w ogóle przejmować ?

Szczerze mówiąc, chyba nie bardzo. Migrowanie istniejących – działających aplikacji jest trochę bez sensu. Tym bardziej, że może się zdarzyć, że pomimo zgodności kodu pewne funkcjonalności zachowają się inaczej i spędzimy sporo czasu testując i poprawiając działający projekt. Tworzenie nowych aplikacji z targetem dla .Net Core jest może nieco bardziej sensowne, chociaż nie jestem przekonany co do tego, że to już ten moment. Klasyczny .Net Framework będzie z nami jeszcze bardzo długo, biorąc pod uwagę jak bardzo integralną część systemu Windows stanowi. Ponieważ zarówno WPF jak i WindowsForms są głęboko związane z platformą Windows, pytanie czy warte to jest zachodu. Pewną przesłanką może być kwestia wydajności, ale bez konkretnych i wiarygodnych benchmark-ów trudno póki co mówić o rzeczywistym skoku jakościowym.

Nie da się ukryć, że pomimo bardzo fajnie wyglądających statystyk pokazanych w początkach wspomnianej wcześniej prezentacji, desktop stał się niszą. Zdecydowanie nie pomijalną, gdyż nadal znajdziemy wiele sytuacji w których aplikacja webowa czy mobilna nie ma zwyczajnie racji bytu – ale jednak niszą. Najlepiej możemy się chyba o tym przekonać zerkając na github. W repozytoriach najbardziej obiecujących projektów cross-platformowego desktopu ze świata .Net – Eto.Forms i Avalonia nie dzieje się tak wiele jak byśmy chcieli. Bardzo obiecująca Avalonia nadal jest w wersji beta i wiele funkcji (chociażby moduł renderujący podgląd na podstawie XAML w VS) działa dość średnio.

2 KOMENTARZE

  1. Ciekawy wpis. Dzięki.
    Szukam informacji odnośnie tworzenia installerów aplikacji desktopowych na Windows’a.
    Coś tam próbowałem z NSIS, InstallShield. Ale pierwsze podejście jest zawiłe, a drugie płatne 🙂
    A jak Ty podchodzisz do tematu installerów? Może coś polecisz. Pozdrawiam

    • Cześć 🙂
      Ja generalnie nie tworzę instalatorów, większość rozwiązań wdrażam po prostu wprost u klienta.
      Pytanie jakiego poziomu skomplikowania oczekujesz w instalatorze i co ma robić poza prostym utworzeniem folderu i skopiowaniem plików z archiwum.
      Jakiś czas temu musiałem coś podobnego przygotować i skorzystałem wtedy z http://installsimple.com/ . Nie ma tutaj zbyt wiele możliwości konfiguracji, ale zrobiło robotę.
      Dawno temu miałem też małe randez-vous z InstallShield, ale generalnie nie byłem zbytnio zadowolony. Korzystałem do testów z traila, a później wydzwaniali w sprawie zakupu licencji.
      Nie mam niestety doświadczeń z żadnym rozwiązaniem, które pozwala na jakieś zaawansowane dodatkowe operacje podczas instalacji.

ZOSTAW ODPOWIEDŹ

Proszę wpisać swój komentarz!
Proszę podać swoje imię tutaj