Dziś krótki artykuł z cyklu „małe a cieszy” 
Chyba każdy programista w trakcie swojego życia zbiera jakieś przydatne kawałki kodu. Niektórzy tworzą z nich drobne biblioteki, inni całe frameworki. To czy jest to praktyka zła, czy dobra nie jest tematem tej rozprawki. Wszystkim nam gdzieś tam jednak przyświeca idea DRY (Do not Repeat Yourself). Jak ją sobie zrealizujemy, to już zależy od nas. Przynajmniej w naszych prywatnych projektach. Z owymi „przydasiami” wiąże się pewien problem. Gdy już stworzymy sobie szereg bibliotek, chcielibyśmy je wykorzystać w różnych projektach.
Osobiście przeszedłem przez etap repozytorium binarek trzymanych w SVN, sciąganych do wyznaczonego katalogu; ręcznego dodawania do nich referencji; czy tworzenia instalatorów WiX, które pakowały binarki do GAC oraz do katalogu z „referencyjnymi bibliotekami”. Miało to tyle wad co zalet, a rozwiązanie z WiXem było dodatkowo pracochłonne.
Na szczęście na horyzoncie pojawił się NuGet.
O tym, czym NuGet jest, chyba nikomu ze światka około .NETowego mówić nie muszę. Gdyby jednak ktoś nie kojarzył, odsyłam na oficjalną stronę projektu, gdzie możecie w szczegółach zaznajomić się z projektem.
W wielkim skrócie to narzędzie, które korzystając ze zdefiniowanych repozytoriów, potrafi dodać do projektu niezbędne referencje, uprzednio ściągając wszystkie potrzebne pliki. Potrafi także wprowadzić zmiany w konfiguracji i wiele, wiele innych fajnych rzeczy. A to wszystko możemy zrobić z poziomu menu kontekstowego w Visual Studio. Bajka!
Myśl, która automatycznie przychodzi do głowy to: „ja chcę takie repozytorium; będę mógł publikować paczuszki, z których będę później korzysał w różnych projektach, a nawet będe mógł się nimi podzielić ze współpracownikami.”.
Istnieje publiczne repozytorium NuGet, ale z pewnością nie chcemy tam umieszczać prywatnych rzeczy (przynajmniej do czasu kiedy zdecydujemy się opublikować wyniki naszej ciężkiej pracy).
Dostępne rozwiązania hostujące repozytoria działają tylko na platformie Windows, a hosting Windowsowy do najtańszych nie należy. Własnego rozwiązania w np. PHP pisać nam sie nie chce. Jak więc sobie z tym poradzić? Dzięki temu, że ktoś wykonał kawałek dobrej roboty i pomyślał, repozytorium NuGet możemy mieć w postaci katalogu z paczkami .nupkg.
Takie repozytorium możemy synchronizować za pomocą Git dla przykładu.
Zanim przystąpimy do pracy musimy zaopatrzyć się w potrzebne narzędzia. Poza instalacja rozszerzenia NuGet do Visual Studio 2010, które począwszy od dodatku Service Pack 1 zainstalowane jest domyślnie, musimy zaopatrzyć się w narzędzie linii poleceń dostepne na stronie projektu, które przyda się do tworzenia paczek.
Zatem do dzieła – stwórzmy i skonfigurujmy repozytorium. Zakładam, że nasze repozytiurm będzie współdzielone pomiędzy kilka osób, zatem gdzieś na dedykowanym serwerze tworzymy puste, współdzielone repozytorium (ja posiłkuję się po stronie serwerowej technologią okołopingwinową, więc takiej będę się tu trzymał). Dla ustalenia uwagi przyjmijmy, że lokalnie repozytorium będzie znajdować się w katalogu D:\Packages. Na serwerze, gdzie hostujemy repozytoria, tworzymy nowe, a następnie klonujemy do wspomnianego katalogu. Katalog ten następnie dodajemy w Visual Studio:
Dodajemy nowe repozytorium wprowadzając nazwę oraz lokalizację na dysku lokalnym:
Repozytorium skonfigurowane. Pozostaje tylko je czymś wypełnić.
Zanim przystąpimy do tworzenia biblioteki musimy wykonać dwa kroki wstępne:
- Do zmiennej systemowej PATH dodać scieżkę do sciągniętego uprzednio pliku NuGet.exe
- Zdefiniować zmienna systemowa PACKAGESDIR (dla przykładu), która będzie wskazywać katalog docelowy na tworzone paczki.
cd $(ProjectDir) NuGet.exe pack $(ProjectFileName) -OutputDirectory $(PACKAGESDIR) -Properties Configuration=Release
W pliku AssemblyInfo.cs dodajemy co najmniej takie atrybuty:
[assembly: AssemblyTitle("SampleLibrary")]
[assembly: AssemblyDescription("SampleLibrary")]
[assembly: AssemblyCompany("ACME")]
[assembly: AssemblyProduct("SampleLibrary")]
[assembly: AssemblyCopyright("Copyright © ACME 2011")]
[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]
Po zapisaniu zmian i przekompilowaniu projektu, w katalogu D:\Packages pojawi się nowa paczka. W powyższym przykładzie opis paczki oraz podstawowe informacje o niej pobierane są z pliku projektu. Jeżeli zależy nam na większej kontroli, możemy utworzyć dla projektu plik .nuspec z dokładną specyfikacją paczki. Szczegóły formatu znajdziecie w dokumentacji projektu NuGet.
Po poprawnej kompilacji możemy zweryfikować, czy paczka jest dostępna. Z menu kontekstowego gałęzi References wybieramy opcję umożliwiającą dodanie referencji do paczki:
Jak widać na załączonym obrazku, nowo utworzona paczka jest gotowa do instalacji:
Pamiętajmy, aby po utworzeniu paczek zsynchronizować repozytorium Git. Inni niech też coś z tego mają
Jeżeli paczki w repozytorium odświeżają się częściej niż ich numery wersji, istnieje konieczność ich ponownego pobrania. Z pudełka nie dostajemy obecnie nic, co by mogło nam w tym pomóc. Po chwili googlania możemy jednak znaleźć potrzebne narzędzie.
Przedstawione rozwiązanie to najprostszy przypadek jaki można sobie wyobrazić. NuGet posiada wiele opcji, z których można skorzystać, aby utworzyć paczki dostosowane do własnych potrzeb. Zachęcam do zagłębienia się w szczegóły. Naprawdę warto!