Pierwsza „książka” WPFowa w naszej bibliotece

Hejo.

Trzeba napisać jakiegoś technicznego posta do DSP, a tu wyjazd i nie ma jak;). Na szczęście jadę dopiero jutro, więc mam jeszcze kilka godzin dnia dzisiejszego, aby coś popisać.

Mam nadzieję, że jakiś kod mimo wszystko powstanie w pociągu, acz z publikacją posta może być gorzej, tak czy inaczej, postanowiłam opisać coś, co może być przydatne na początku kariery, jednocześnie nie jest to żadne rocket science wymagające większego przygotowania.

A więc…

Istnieją pewne elementy, które nie są specyficzne dla projektu. Do nich możemy zaliczyć kontrolki, konwertery, jakieś nakładki na winapi, tego typu rzeczy. Dla kodu mamy extract method, a dla elementów projektu? „Extract project”… hehe czyli możliwość stworzenia biblioteki. Oczywiście biblioteka jest takim specyficznym projektem, który jest jak wirus- aby żyć, musi zostać dodany do innego projektu. Sam nie ma mocy uruchomienia się.

Zrobimy więc sobie jedną dla takich „raw” rzeczy, jedną dla GUI.

Dla raw, nie problem. Po prostu dodajemy nowy projekt w ramach tej samej solucji. Korzystamy z szablonu „Class library” przygotowanym właśnie do tego celu.

Z WPFem ostatnim razem „WPF control library” działało w wersji bodajże 2010, a potem już trzeba sobie było szablon zrobić samemu. Nie jest to jakieś arcy trudne i sprowadza się do wykonania następujących kroków.

1. Tworzymy pusty projekt wpfowy i zmieniamy output type na class library. Wywalamy okno główne (mam tu na myśli MainWindow.xaml czy cokolwiek analogicznego), oraz app.xaml bo jak napisano powyżej- nie chcemy mieć możliwości uruchamiania jako aplikacji, co w ustawieniu output type powiedzieliśmy, a następnie dodajemy pierwszą kontrolkę.
2. Budujemy, jak przeszło to file→ export template, po czym wybieramy []project template i z combo boxa nasz projekt co udaje libkę. Potem wpisujemy cokolwiek, a następnie tworzymy projekt z nowego template (lub korzystamy z aktualnego projektu- nada się).
3. Teraz tylko dodać referencje i można używać;)

W moim projekcie postanowiłam przenieść do nowego liba kontrolkę stworzoną poprzednio i zacommitować zmiany, a także sprawić, by projekt przynajmniej działał jak poprzednio.

O czym należy pamiętać, jeśli się przenosi coś do liba:

1. O zaktualizowaniu namespace’ów w projekcie
2. O przeniesienie wszystkiego, co zależy od przenoszonego obiektu (linkowanie w bibliotece do projektu głównego to zła praktyka- chyba się domyślacie dlaczego).
3. O podpięcie referencji do nowego projektu (ale po pierwszym zbudowaniu, bo inaczej jest wykrzyknik, który rozprasza. )
4. O zbudowaniu projektu z kontrolką (a o tym właśnie zapomniałam:) – na szczęście kochany VS mi o tym szybko przypomiał.

Po tych zabiegach kontrolka powinna być widziana w toolboxie zaś „raw” funkcje i klasy powinny mieć opcję podpowiadania.

Możliwości użycia takich bibliotek są dwie. Pierwsza z nich, to dodanie referencji do projektu, druga, do dllki, która się nam skompiluje. Zaletą dllki jest to, że możemy ją użyć w innym projekcie, a nawet dać komuś (pamiętaj, aby skompilować ją w wersji „release” zanim dodasz do „proda”). Kolejną zaletą jest brak zależności pomiędzy kodem „bibliotecznym” a naszym głównym projektem. Tzn mamy pewność, że lib sam z siebie do działania nie będzie potrzebował kodu z głównej apki, więc nie podkusi nas by wysłać jej za dużo i zadbamy o tę separację.

Piatkosia, kiedy w końcu przestaniesz się bawić i zaczniesz dostarczać to, czego oczekuje od ciebie „strona biznesowa”. Weź w końcu usuń pana Zenka z zablokowanych numerów.

Heh, nie wiem. Może kiedyś. A poza tym to mój czas wolny i będę go spędzać jak będę chciała :p

PS dziś nie wklejam kodu.  Jest na githubie. Wiecie gdzie.