Bez kategorii

Zakładanie projektu i problemy z Visual Studio 2017 RC

W poprzednim wpisie mówiłem, że przy okazji projektu chcę poznać najnowsza wersję Visual Studio. Choć jest ono jeszcze w wersji RC(Release Candidate), to od kilku osób słyszałem, że jest na tyle stabilne, że pracują na nim na co dzień. Ale te osoby chyba nie mają projektów w Xamarinie, a przynajmniej nie muszą ich zakładać. Ale po kolei.

Decyzje

Przy tworzeniu projektów w Xamarinie mamy do podjęcia kilka decyzji. Po pierwsze, czy tworzymy aplikacje na jedną platformę, czy na wiele. Ja wybrałem tworzenie aplikacji cross-platformowej, żeby sprawdzić jak działa dzielenie kodu między projektami. Musimy też wybrać, czy tworzymy nasze aplikacje jako natywne, czy w Xamarin Forms.

Aplikacje natywne są lepsze, gdy chcemy używać funkcji specyficznych dla danej platformy. Musimy wtedy tworzyć między innymi oddzielne wyglądy dla każdego z systemów. Xamarin Forms mają tą zaletę, że dzielimy kod między wszystkimi platformami, łącznie z wyglądem. Ja zdecydowałem się na tworzenie aplikacji w Xamarin Forms.

Kolejną decyzją do podjęcia jest to czy chcemy pisać kod w projekcie współdzielonym, czy jako PCL(Portable Class Library). Zdecydowałem się na tworzenie projektu w PCL, jako, że jest on łatwiejszy do testowania. Inne różnice przedstawia ten artykuł. I wtedy zaczęły się problemy.

Utworzenie projektu, tylko że nie bardzo

W Visual Studio 2017 RC nie ma możliwości utworzenia projektu Cross-platform Xamarin Forms PCL. Podejrzenie oficjalnych projektów zespołu Xamarina na Githubie pokazało mi jak projekt taki powinien wyglądać. Postanowiłem więc poskładać go z modułów, dodając poszczególne projekty osobno. Tak więc dodałem projekt: Class Library, iOs, Android i UWP. Teraz zostało tylko je spiąć, prawda? Więc lecimy: dodajemy referencje do każdej platformy, zmieniamy nazwy klasy wywoływanej przy uruchomieniu. Powinno działać. Ale nie działa. Cały dzień Googlania nie przyniósł rezultatów. Dowiedziałem się tylko, że w Visual Studio 2015 tworzenie takiego projektu jak chcę jest out-of-the-box. Natomiast dla developerów Xamarina problem z Visual Studio 2017 jest znany i mają nadzieję, że w ostatecznym wydaniu VS 2017 będzie możliwe utworzenie takiego projektu. Postanowiłem nie czekać na oficjalne wydanie IDE od Microsoftu, które ma nastąpić 7 kwietnia 2017. To tydzień po starcie konkursu.

Rozwiązanie jest już blisko…

Pomyślałem, że dezinstalacja Visual Studio 2017 RC i instalacja wersji 2015 rozwiąże mój problem. Jak bardzo się myliłem. Przyniosło to skutek, bo mogłem utworzyć taki projekt jaki mnie interesował, ale niestety nie dało się go poprawnie zbudować. Znowu udałem się po pomoc do Internetu. Okazało się, że Xamarin psuje się przy przejściu między wersjami 2017 i 2015. Odinstalowałem Visual Studio i Xamarina wraz z wszystkimi dodatkami i komponentami. Wyrzuciłem też wszystkie foldery, które po nich pozostały. Ponowna instalacja Visual Studio 2015. Teraz wszystko powinno grać. Ale nie grało. Visual Studio się odpalał… I to by było na tyle. Nie dało się na nim nic zrobić. Zawieszał się od razu po starcie. Nie pozostało mi nic innego jak…

Stary dobry format

Na szczęście w Windowsie 10 jest taka magiczna opcja przywrócenia do stanu początkowego. Trwa to ok pół godziny i mamy czysty system. Później zostaje najgorsze, czyli instalacja wszystkich potrzebnych programów. Z pomocą przychodzi jednak Ninite i Chocolatey.

Po zainstalowaniu Visual Studio 2015 i Xamarina wszystko działa tak jak powinno od początku.

Zakładanie projektu

Teraz zostaje tylko opisać to o czym pierwotnie miał być ten post, czyli zakładanie projektu. Z menu File w Visual Studio wybieramy New i następnie Project. Teraz trzeba wybrać język, czyli C# i rozwinąć jego zakładkę. Jako, że tworzyć będę aplikację cross-platformową, wybieram pozycję Cross-Platform. Zgodnie z decyzją jaką podjąłem pisać kod będę w PCL. Wybieram więc Blank Xaml App(Xamarin.Forms Portable). Nie wyjaśniłem jeszcze jednego zagadnienia z tej nazwy: Xaml. Jest to język znaczników podobny do XMLa, w którym tworzy się interfejsy. Następnie kod pracujący na tym interfejsie umieszczamy w tak zwanym code behind. Można wybrać taka samą nazwę, ale bez Xaml. Wtedy wygląd tworzymy w C# i nie musimy go okodowywać w code behind, tylko bezpośrednio w tym samym pliku. Dla mnie tworzenie interfejsów w XMLu/XAMLu jest bardziej naturalne, więc wybrałem akurat tą opcję. Jednak to nie ma znaczenia, gdyż możemy część widoków tworzyć w XAMLu, a część w C#.

Zostanie utworzone kilka projektów, między innymi na iOS, Androida, czy UWP(Uniwersal Windows Platform). Zamykamy Visual Studio w celu zmiany nazwy katalogu. Jeśli przejdziemy w miejsce na naszym dysku w którym utworzyliśmy powyższą solucję zobaczymy kilka folderów. Między nimi packages i folder nazwany tak samo jak nasz projekt Xamarin.Forms. W nim znajdziemy foldery zawierające projekty na wszystkie platformy. Możemy to poznać po ich nazwach(iOS, Droid, UWP). Zdałoby się zmienić jego nazwę, żeby zachować konwencje o której pisałem w poprzednim wpisie. zmieniamy jego nazwę na src. Następnie musimy dodać wszystkie projekty do solucji w Visual Studiu. Robimy to poprzez: kliknięcie prawym przyciskiem myszy na naszej solucji -> Add -> Existing Project i wybraniu pliku .csproj dla projektu każdej platformy. Możemy usunąć stare projekty, przy których jest napis (unavailable).
To oczywiście nie jest konieczny proces. Możemy te projekty zostawić w domyślnym folderze, który utworzył dla nas Visual Studio.

Dodawanie projektu z testami

Jak wspomniałem w poprzednim wpisie, przy okazji Daj się poznać 2017 będę chciał nauczyć się pisać testy jednostkowe. Do tego celu utworzę kolejny projekt, tym razem zwykłe Class Library. Wiec klikamy prawym przyciskiem na nazwę solucji. Wybieramy Add, następnie New Project. Z listy wybieramy Class Library. Nie zapomnijmy tylko, jako lokalizację wybrać katalog_projektu/tests żeby zachować porządek w plikach. O rozkładzie projektu pisałem już w ostatnim wpisie. Pozostało tylko dodać pakiet Nuget o nazwie xUnit. Najłatwiej zrobić to za pomocą komendy w konsoli Package Manager: install-package xunit Codziennik.Tests. Dzięki temu będziemy mogli uzywać biblioteki xUnit do pisania testów jednostkowych.

Aktualny stan projektu możesz zobaczyć na moim Githubie. Stan kodu jaki miałem po napisaniu tego wpisu mozesz zobaczyć pod tagiem 01-project-setup

Przez chęć poznania nowego środowiska zmarnowałem 3 dni. Wkurzałem się dziesiątki razy, że mogłem mieć już tyle zakodowane, a muszę walczyć z durnymi narzędziami. Bardzo dobrze podsumowuje to obrazek, który ostatnio wrzucił na Facebooka Maciej Aniserowicz.

Z całej tej walki płynie jeden morał. Najpierw sprawdź czy na nowszym oprogramowaniu działa to co chciałeś zrobić, a dopiero potem instaluj je jako swoje główne.

Zostaw odpowiedź

Twój adres email nie zostanie upubliczniony.* Pola wymagane *

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.