Pewnie bardzo często dodawałeś nową zależność w projekcie. Klikałeś opcję “Manage NuGet Packages…”, wybierałeś pakiet i go instalowałeś. Może w Twojej głowie przemknęła wtedy myśl:
Ciekawe skąd się biorą pakiety NuGet?
Miałem podobnie i postanowiłem przetrzeć szlaki, i mieć własnego NuGet’a!
Swoje działania bardzo mocno opierałem na poście Andrew Locka pt. Publishing your first .NET Core NuGet package with AppVeyor and MyGet. Zachęcam do lektury postu Andrew, a następnie powrotu tutaj.
Różnice i podobieństwa
Moje podejście nieznacznie się różni, gdyż u mnie zamiast .NET Core jest .NET Standard, a MyGet’a jest zastąpione roboczym repozytorium AppVeyor.
Musiałem również nieznacznie zmienić skrypt Build.ps1, gdyż ścieżka bezwzględna z oryginalnego rozwiązania nie działała i musiałem ją zastąpić ścieżką względną. Zmieniona wersja pliku Build.ps1 dostępna jest w moim repozytorium.
Proces zaproponowany przez Andrew idealnie opisuje mój wymarzony scenariusz dla publikowania Nuget’a:
- Każdy commit inicjuje build, który zapewnia wszystkich o tym, że kod się buduje i przechodzi testy
- Merge pull requesta do mastera skutkuje kolejnym buildem i wrzuceniem pakietu NuGet do prywatnego repozytorium na AppVeyor
- Otagowanie zmiany na branchu master równoważne jest releasowi, czyli w moim przypadku oznacza wrzucenie pakietu NuGet do publicznego repozytorium na NuGet.org
AppVeyor
Jest to to serwer buildów, bezpłatny dla projektów open source. Jego głównym atutem jest to, że jako jeden z nielicznych wspiera projekty oparte na .NET Framework. Jak wiadomo, ta wersja .NET’a nadal króluje w świecie Enterprise.
Konfiguracja builda odbywa się na jeden z dwóch sposobów:
- Wyklikanie procesu na portalu AppVeyor
- Dodanie pliku appveyor.yml do projektu
Wybrałem opcję nr 2, gdyż takie podejście umożliwia wersjonowanie zmian w procesie budowania aplikacji, nie wiąże nas z jedną instancją serwera a równie dobrze potrafi zabezpieczyć nasze sekrety (np. ApiKey do NuGet’a, o czym też pisze Andrew w swoim poście).
AppVeyor udostępnia nam również dwa źródła pakietów NuGet’woych: jedno skojarzone z kontem użytkownika, drugie z kontem projektu.
Wygenerowanie NuGet ApiKey dla AppVeyor
Ten krok przyda się za chwilę, ale skoro jesteśmy przy AppVeyor, to omówię go już teraz.
Aby wygenerować ApiKey dla konta użytkownika AppVeyor należy przejść do zakładki Settings->NuGet i kliknąć “Generate new API key”.
Pomysł na NuGet
Uznałem, że dobrym kandydatem na mój projekt open source jest stworzenie klasy bazowej dla silnie typowanych identyfikatorów. Już któryś raz w swojej karierze piszę taką klasę od nowa, a mógłbym zaciągnąć swojego NuGet’a.
Samo podejście do tego tematu jest opisane w moim poście Strongly Typed Identifiers in .NET revealed. Na potrzeby klasy bazowej musiałem lekko zmodyfikować kod, co też możesz zobaczyć w moim repozytorium na GitHub. Znajduje się tam klasa TypedId, która jest klasą bazową dla innych, silnie typowanych identyfikatorów.
Ten etap mamy już gotowy, Twój kod leży sobie bezpiecznie w repozytorium na GitHubie i czeka, aby zamienić się w ogólnodostępnego NuGet’a.
Plan gry
Nasze dalsze kroki można podsumować w punktach poniżej, jednak gorąco zachęcam do lektury postu Andrew Lock’a, aby poznać szczegóły.
- Integracja AppVeyor z GitHub (bardzo proste i szybkie do wykonania przez Marketplace na GitHub’ie)
- Wygenerowanie ApiKey dla swojego konta na NuGet.org oraz dla prywatnego repozytorium na AppVeyor
- Dodanie pliku Build.ps1, który potrafi zbudować nasz projekt i spakować do pakietu Nuget
- Dodanie pliku appveyor.yml, który zawiera instrukcje budowania aplikacji dla AppVeyor
- Sprawdzenie całego flow
Pakiet na NuGet.org będzie zaindeksowany i publicznie widoczny nawet po kilkunastu minutach, więc warto sprawdzać bezpośrednio na swoim koncie na NuGet.org, czy release się udał.
Pochwalcie się swoimi pakietami Nuget w komentarzach poniżej!
