Wpis z mikrobloga

TL;DR : mój rant o tym, że UWP to antyludzki syf z gównianym toolingiem, będący w permanentej becie.

Chciałem dla własnej frajdy napisać małą aplikację desktopową na Windę (domena problemu mocno wykluczała weba, bo chodziło głównie o mielenie po dysku użytkownika); po szybkiej analizie dostępnych platform wybrałem UWP, uznając, ze po 4 latach platforma dojrzała i da się z nią pracować, szczególnie, że niedawno musiałem trzasnąć w niej malutką appkę i nie wyszło źle. Tu chciałem zrobić coś pełnoprawnego i w pełni koszernie, a styl wizualny UWP bardzo mi pasował do tematu.

O ja #!$%@? naiwny. Taki stary, a taki głupi.

Próba dodania projektu z testami jednostkowymi to już nieco za dużo dla zajebistego toolingu UWP w Visual Studio. Ze względu na podjęte decyzje dot. bezpieczeństwa aplikacji UWP, nawet #!$%@? testy jednostkowe są odpalane wewnątrz specjalnej instancji aplikacji. Nie zdołałem nawet doprowadzić do odpalenia prostego testu z użyciem xUnita, to za dużo dla narzędzi UWP w Visualu. Predefiniowana templatka z MSTestem ujdzie, xUnit niet. Nawet nie będę zaczynał tematu braku frameworków mockujących przez brak Reflection.Emit() w .NET Native.

Ok, spróbujemy WPFa z XAML Islands, to już ma trochę czasu na rynku. Pominę sen wariata z konfigurowaniem aplikacji WPFowej, żeby mogła w ogóle używać komponentów UWP. 30 minut rzeźby z dokumentacją Microsoftu i... tak, zgadliście, #!$%@? wielki i bąbelki! Appka WPFowa i appka UWP mająca robić za host są niekompatybilne i #!$%@?. Dobra, zaktualizowałem SDK, zaciągnąłem wszystkie nowe SDK, nic. Dalej nie działa. Zaciągnąłem przykładową aplikację WPFową z XAML ISlands z GitHuba - nawet się nie zbudowała.

Jeśli ktoś gdzieś w Redmond jeszcze zakłada, że UWP odniesie jakikolwiek sukces, zalecam wyjęcie głowy z dupy. Decyzje podjęte na etapie projektowania platformy sprawiły, że rzeczy przyjęte za oczywiste w developmencie na każdą #!$%@? inną plaftormę w UWP urastają do rangi problemu na pół dnia. #!$%@?, robiłem w tym komercyjnie i majac dosyć gównianego supportu uciekłem w .NETa Core i backendy. Po dwóch latach i powrocie widzę, że absolutnie nic się nie zmieniło, UWP dalej ssie pały i aktywnie utrudnia developerowi najprostsze rzeczy.

Koniec żali. Appka będzie chyba w czystym WPFie pod .NETem Core.

#programowanie #csharp #dotnet #uwp #wpf
  • 13
@Czesiowcy:

Decyzje podjęte na etapie projektowania platformy sprawiły, że rzeczy przyjęte za oczywiste w developmencie na każdą #!$%@? inną plaftormę w UWP urastają do rangi problemu na pół dnia.

Szczerze mówiąc mam wrażenie, że tak wygląda pisanie wszystkiego pod desktop :D W C++ też potrafiłem się dzień j**ać z czymś, co w takim przykładowo androidzie zajmuje 2 minuty.
A to nie może znaleźć ścieżek do czegoś, a to biblioteka mu się
@Zelber: Wiesz co, prozaiczny przykład, który już wymieniłem - osobny projekt z testami. W WPFie (i zapewne w WinFormsach) dopinasz generyczny .NETowy projekt testów jednostkowych i gra i buczy. Jedyny wyjątek to testy kontrolek UI, ale nawet to da się ogarnąć, a testowane klas niezwiązanych stricte z frameworkiem UI nie wymaga żadnych fikołków. W UWP projekt testowy to jakiś customowy pasztet, a jego przymuszenie do współpracy wymaga cierpliwości i grzebania w
a wiadomo że potrafią zrobić przecież dobry produkt


@Koliat: Temu się nie mogę nadziwić, bo przeca ta sama firma robi #!$%@? .NETa Core i ASP .NET Core - ze świetnym toolingiem i bardzo szeroką i aktywną społecznością. Kij, innym przykładem jest F#, który jak na języki funkcyjne ma po prostu niesamowity tooling i wsparcie może mniejszej, ale bardzo oddanej społeczności.

A, F# też nie da się używać w UWP, bo .NET
@Czesiowcy: z UWP nie korzystam ale z xunitem/nunitem problemów nie mialem budujac ostatnio w Core 3.1 WebAPI bazujac na templateach Clean Testing i Clean Architecture. Nie bardzo rozumiem dlaczego po prostu nie zrobisz frontu w Asp.Net Core lub Blazorze a backendu na worker services albo konsoli z komunikacją przez SignalR bądź gRPC?
z UWP nie korzystam ale z xunitem/nunitem problemów nie mialem budujac ostatnio w Core 3.1


@bacteria: Mówiąc krótko, odpisujesz nie na temat. No offence. Ja również nie mam problemów z xUnitem w Corze, zarówno pod WPFa, jak i pod ASP .NET Core.

Nie bardzo rozumiem dlaczego po prostu nie zrobisz frontu w Asp.Net Core a backendu na worker services albo konsoli?


Bo to #!$%@? z armaty do wróbla, żeby wrzucić ładnie
@Czesiowcy: Możesz rozwinąć problem z testami? Jaki framework? .NET Core czy .NET. Załóżmy, że mam strukturę solucji:
- MyApp.UI (UWP)
- MyApp.Core (Class Library/.NET Standard)

Dodaje nowy projekt MyApp.Core.Tests i jako runnera używam Xunit. Dlaczego miałoby to nie dzialać, jeżeli testuję obiekty w zwykłej class library, nie związanej z konkretnym frameworkiem warstwy prezentacji? Rozumiem, ze mogą być problemy z testowaniem projektu MyApp.UI, który używa UWP, ale z Class Library? W Clean
@markaron: Panie, miej Boga w sercu. To jest prosta aplikacja desktopowa, w której chcę sobie sprawdzić w sposób zautomatyzowany przepływy i, co najważniejsze, poprawność działania warstwy prezentacji na poziomie viewmodeli, bo testowanie widoków w UWP to kolejny sen wariata. A tu sru, znowu armata i wróbel. A Ty jeszcze wyskakujesz z domeną, chociaż tutaj wyszedłby może jeden agregat domenowy na krzyż. Pomijając to, że mogę mieć też zdefiniowane własne komponenty Windows
@Czesiowcy: ja sie zastanawiam czy oni w ogóle robią te frameworki i toole jako produkt a nie projekt pod konkretnego klienta. Kiedyś chciałem sobie coś napisać w react-windows (react pod windowsa, super to wygląda na papierze, miljony gwiazdek na github). Po czym okazuje się ze coś takiego jak np. axios.js (podstawowa biblioteka w reactcie) nawet nie jest wspierane. I w issue na githubie ticked closed bo uwaga:

our clients found different
Podejrzewam, że tak jest też z uwp i więszkością bibliotek od microsoftu.


@PoteznyMagWody: UWP jest stopniowo odklejane od release'ów wersji Windowsa i teraz usiłują jego elementy (patrz : WinUI) pchać do pozostałych frameworków aplikacyjnych pod Windę. UWP miało sens (...jako taki...), gdy istniała mobilka Windowsowa. Gdy ten ambitny projekt upadł, sens tworzenia aplikacji uniwersalnych obejmujących desktop i jakieś drobnice zaginął.

Bardzo zaskoczony byłem tym, że Avalonia - framework, który pisały 3