@rek online

Kontynuując serię postów filozoficznych z początku konkursu dzisiaj będzie o systemie kontroli wersji.

Dlaczego system kontroli wersji jest nam potrzebny?

1. Dzięki temu możemy w każdym momencie wrócić do wcześniejszej wersji naszego projektu. To też wymaga od nas abyśmy regularnie zwracali (wykonywali commit, checkin w zależności od systemu kontroli wersji) kod.
2. W razie awarii komputera, mamy backup naszych źródeł czyli największego aktywa w przypadku firm/osób zajmujących się tworzeniem oprogramowania
3. ….i najważniejsze. Możemy pracować w zespole, w którym każda osoba pracuje nad inną częścią programu. System kontroli wersji ułatwi nam utrzymanie źródeł w całości i prawidłowe łączenie zmian wszystkich osób z głównym projektem
4. …oczywiście są dodatkowe plusy, takie jak możliwość rozproszenia programistów po całym świecie
5. Zwiększenie jakości kodu
6. Zwiększona kontrola nad poczynaniami pracowników etc

Można by wymieniać dalej, ale uważam, że trzy pierwsze powody są najważniejsze dla pytania po co nam system kontroli wersji.

Na potrzeby konkursu skorzystałem z CodePlex-a który daje możliwość korzystania z TFS-a. Pełny Team Foundation Server jest potężnym narzędziem do zarówno kontroli wersji jak i zarządzania projektem, zarządzania błędami, testami, buildami, projektem architektury, bazy etc. Narzędzie to, to wprost niesamowity kombajn – niestety kosztuje również jak nowy kombajn zbożowy. CodePlex daje nam namiastke tego. Wybierając dla naszego projektu Visual Studio Team Explorer dostajemy namiastkę płatnej wersji TFS-a. To czego w tym momencie potrzebujemy to zainstalowanie Team Explorera – czyli klienta TFS-a który jest do pobrania ze stron CodePlex. Paczka waży około 300MB i spotkałem się już z głosami że tyle aby tylko dostać się do źródeł to przesada ale Team Explorer to nie tylko dostęp do źródeł więc nie ma sensu tutaj w ogóle podejmować takich dyskusji.

Zainstalowałem Team Exporer – co dalej?

Po instalacji w Visual Studio mamy dostęp do nowej zakładki – Team Explorer

Korzystając z CodePlex-a nie mamy tutaj zbyt wiele bo tylko Work Items oraz Source Control – do tej pory nie udało mi się wykorzystać Builds-a (a trzeba wspomnieć że korzystając z pełnego TFS-a tutaj możemy uruchamiać automatyczne buildy, które skompilują wersję, uruchomią testy jednostkowe oraz testy przygotowane przez testerów, mogą spakować wersję do zip-a i opublikować na serwerze a w wersji TFS2010 również uruchomić maszynę wirtualną, na niej zainstalować skompilowaną właśnie paczkę, przeprowadzić testy i przywrócić maszynę wirtualną do stanu sprzed testów).

To co oprócz przechowywania źródeł nas tutaj interesuje to owe Work Items:

Otwierając All Work Items mamy możliwość przeglądania wszystkiego co mamy do wykonania oraz tworzenia nowych Work Items-ów czyli nowych rzeczy do wykonania

To co tutaj możemy zrobić to przegląd istniejących zadań, możemy ich listę wyeksportować do Excel-a do dalszych analiz

Lub przesłać Outlookiem. W końcu sami możemy modyfikować zapytanie, za pomocą którego pobierane są wszystkie WorkItemy poprzez edycję zapytania (Query)

W gałęzi Team Queries     znajdziemy dwa elementy All Work Items oraz My Work Items. To pierwsze to po prostu lista wszystkich rzeczy do zrobienia, drugie natomiast to rzeczy przypisane do mnie.

Jak zatem tworzyć WorkItemy?

Wybierając prawy klawisz na pozycji WorkItems możemy łatwo i szybko stworzyć nowy WorkItem.

Teraz co pozostaje to opisać typ, priorytet, komponent do którego będzie przypisany WorkItem, kto ma się tym zając (jeśli pracujemy w większym zespole), status i kiedy planowany release tej funkcjonalności. Oczywiście mamy miejsce na opis, komentarze oraz możemy załączać dodatkowe pliki jak na przykład projekty wyglądu czy dodatkowe specyfikacje.

A teraz najważniejsze…. Wszystko to co tutaj sobie gromadzimy, w przypadku CodePlex-a dostępne jest na stronie naszego projektu. U mnie rzeczy do zrobienia znajdują się tutaj

Dodatkowo można na stronie głosować na konkretne funkcjonalności ale to nie wiem jak działa ponieważ jeszcze nikt nie głosował

Pozostaje mi jeszcze wspomnieć o jednym. WorkItemy warto zapisywać nie tylko dlatego że możemy prowadzić listę rzeczy do wykonania w naszym projekcie, ale również możemy workItemy wiązać z konkretnym kodem.

W momencie zwrotu kodu do repozytorium (w TFSie Check In) możemy z kodem związać WorkItem który wykonaliśmy.

Nie wiem jakie możliwości mają inne online-owe narzędzia kontroli wersji dlatego nie porównuję ich. Jeśli ktoś z was ma chwilę na opisanie swojego rozwiązania, chętnie poczytam i poszukam innego narzędzia o podobnych możliwościach.

Zwracam się z prośbą do wszystkich czytelników. Chcę abyś zainstalował i uruchomił przynajmniej 2 razy aplikację DesktopInfo, którą można pobrać stąd. Sama aplikacja zajmuje kilka kilo więc nie jest to jakieś obciążenie.

Teraz najważniejsza rzecz, dlaczego zwracam się do Ciebie z taką prośbą? W nowej wersji chcę przetestować publikację ClickOnce na CodePlex – która trochę się różni od normalnej publikacji ClickOnce ale nie wyprzedzajmy faktów oraz przetestować możliwość monitorowania ilości uruchomień aplikacji. Użytkownicy CodePlex mają możliwość zbierania informacji o ilości uruchomień aplikacji dzięki uprzejmości firmy PreEmptive. Aplikacja zbiera informacje odnośnie ilości uruchomień i prawidłowych wyłączeń aplikacji, można monitorować wykorzystanie różnych funkcji programu (tego na razie nie używam), system operacyjny, wersję .net oraz lokalizację użytkowników z „dużym przybliżeniem” – a dlatego w „” ponieważ uruchamiałem tą aplikację na swoim komputerze, który znajduje się w Bielsku-Białej a na mapie znajdziecie 4 uruchomienia w Warszawie J

Z góry dziękuję za pomoc oraz uwagi i pytania jeśli takowe Masz.

Wczoraj wieczorem opublikowana została pierwsza (zerowa) wersja aplikacji DesktopInfo. Na chwilę obecną nie robi wiele poza wyświetlaniem zegara na pulpicie. Wersja mimo wszystko została opublikowana ponieważ najwyższa pora pokazać, że to coś może działać. Z rzeczy najważniejszych jakie trzeba będzie zrobić to zaimplementowanie mechanizmu ładowania dodatkowych bibliotek (tutaj najprawdopodobniej będzie to MEF alternatywnie własny mechanizm oparty na refleksji).

Wersja jest do pobrania z tego miejsca (DesktopInfo instalka). Publikacja została oparta o mechanizm ClickOnce, który pozwala na bezproblemowe aktualizacje – i tak po wypuszczeniu kolejnej wersji to co zostało zainstalowane automatycznie się zaktualizuje. Dodatkowo, ten sposób publikacji pozwala na instalację aplikacji bez uprawnień administratora lokalnego – aplikacja instaluje się gdzieś w folderach tymczasowych – nie pozwala na zaśmiecanie systemu w różnych dziwnych miejscach i dodaje dodatkowe ograniczenia. Jednym z nich, który będzie dla mnie irytujący (czyt. problematyczny do przeskoczenia) to brak możliwości wpisania się do autostartu ale to zostawiam na później.

Wszystkich zainteresowanych postępami w rozwoju aplikacji zapraszam do instalowania oraz do wpisywania uwag, sugestii, pytań.

Podczas zapoznawania się z ASP.NET .oraz MVC2 trafiłem na coś, co jest bardzo denerwujące. Mianowicie strony aspx nie są kompilowane podczas kompilacji samego projektu. Jaki jest tego skutek? Dodatkowa robota w poszukiwaniu błędów wynikających z literówek. Jednak do rzeczy….

Moja testowa aplikacja wypluła taki błąd:

Server Error in ‘/’ Application.

Compilation Error

Description: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.

Compiler Error Message: CS1002: ; expected

Source Error:

Z czego widać, że brakuje ; w linii 16-tej. Prosta i oczywista sprawa, jednak trochę irytująca, ponieważ podczas kompilacji Visual Studio nie poinformowało mnie o tym problemie, trafiłem na niego dopiero ruszając ten konkretny kawałek kodu przechodząc na odpowiednią stronę.

Co gorsze, jak otworzymy odpowiedni plik, wówczas VS raczy nas poinformować o błędzie:

Zatem jak sobie z tym poradzić?

Należy włączyć kompilację stron aspx. W tym celu wystarczy wyłączyć projekt

Poprzez wykonanie unload Project a następnie wprowadzić zmiany w pliku csproj

To co nas interesuje to wpis MvcBuildViews.

Zmieniając tą wartość na true powodujemy, że Visual Studio będzie kompilować również strony aspx i każda literówka jak wyżej zostanie wyłapana przy pierwszej kompilacji. Zatem po wprowadzeniu zmiany pozostaje zapisać zmiany w pliku oraz załadować projekt ponownie.

Wreszcie podczas kompilacji dostajemy błąd:

Pozostaje dodać zapomniany ; i pracować dalej.

Dzisiaj miał być wpis o konfiguracji narzędzi z jakich będę korzystał przy projekcie, jednak złośliwość komputerów bywa niesamowita. Jednak po kolej.

Aby zainstalować Visual Studio 2010, które przyszło z MSDN AA musiałem najpierw pozbyć się wcześniejszej wersji beta, która oprócz tego, że była beta to jeszcze wygasła. Sprawa wydawało by się prosta. Panel Sterowania -> Programy -> Uninstall prosta sprawa. Tyle tylko, że SQL nie chciał się usunąć, jakoś mu się spodobało u mnie na dysku i postanowił zostać. (un)Instalator stwierdził:

„Invoke or BeginInvoke cannot be called on a control until the window handle

has been created.”

Aby to przeskoczyć, okazało się, że wystarczyło na dysku c założyć katalogu temp. I tak tworząc folder c:\temp instalator ruszył dalej. Niestety nie na długo. Instalator stwierdził, że potrzebuje restartu aby kontynuować dalej. Kilkanaście restartów później dalej twierdził, że aby kontynuować potrzebuje restartu. Jak zatem temu zaradzić?

Otwierając regedit w gałęzi Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Control\Session Manager znajdziemy klucz PendingFileRenameOperations. Po usunięciu tego wpisu można w instalatorze wybrać opcję refresh zamiast restartować cały system a następonie spokojnie przejść do pozbywania się SQL-a.

Problemy te pojawiły się podczas usuwania testowej wersji Visual Studio 2010 na Windows 7 x64.