2013-05-31 35 views
6

Jestem w trakcie wprowadzania NuGet do naszego procesu tworzenia oprogramowania, zarówno dla zewnętrznych plików binarnych (np. Moq, NUnit), jak i dla projektów bibliotek wewnętrznych zawierających wspólną funkcjonalność.Referencje projektu v Zależności NuGet

TeamCity produkuje pakiety NuGet z naszych wewnętrznych projektów bibliotecznych i publikuje je w lokalnym repozytorium. Moje zmodyfikowane pliki rozwiązania używają lokalnego repozytorium do uzyskiwania dostępu do pakietów NuGet.

Rozważmy następujące rozwiązania kodu źródłowego:

  1. Company.Interfaces.sln buduje Company.Interfaces.1.2.3.7654.nupkg.
  2. Company.Common.sln zawiera odniesienie do Company.Interfaces poprzez opakowania Nuget i opiera Company.Common.1.1.1.7655.nupkg z Company.Interfaces.1.2.3.7654 włączone jako zależność.
  3. Firma Company.DataAccess.sln używa Company.Common nupkg, aby dodać Company.Interfaces i Company.Common jako odniesienia. Kompiluje on Company.DataAccess.1.0.8.7660.nupkg, w tym Company.Common.1.1.1.7655 jako składnik zależny.
  4. Company.Product.A to rozwiązanie internetowe, które zawiera odniesienia do wszystkich trzech projektów bibliotecznych (dodane przez wybranie pakietu Company.DataAccess NuGet).

Pytania:

Jeśli istnieje kod źródłowy zmiana Company.Interfaces, mam zawsze trzeba zmienić numerację i odbudować pakiety pośrednie (Company.Common i Company.DataAccess) oraz aktualizować pakiety w Company.Product.A?

Albo czy to zależy od tego, czy zmiany kodu źródłowego był

  • bug fix lub
  • nowa funkcja lub
  • łamanie zmiana?

W rzeczywistości mam 8 poziomów zależnych pakietów bibliotecznych. Czy istnieje wsparcie narzędziowe do aktualizacji całego drzewa pakietów, jeśli to konieczne?

Wiem o wersji semantycznej.

Używamy VS2012, C# 4.0, TeamCity 7.1.5.

Odpowiedz

3

Dobrze jest zaktualizować wszystko przy każdym zameldowaniu, aby przetestować je wcześniej.

To, co opisujesz, można łatwo zarządzać za pomocą zależności artefaktów (http://confluence.jetbrains.com/display/TCD7/Artifact+Dependencies) i wyzwalaczy budowania "Zakończ buduj" (lub nawet wyłącznie "Wyzwalanie zależności Nuget").

1

Napisaliśmy własną konfigurację kompilacji na bazie projektu (będzie to Company.Interfaces.sln w tym przypadku), który buduje i aktualizuje całe drzewo za jednym razem. Sprawdza w trakcie aktualizacji zaktualizowane pliki packages.config i .nuspec. Nie potrafię powiedzieć, ile zaoszczędziłoby czasu, który dla nas byłby, nawet gdyby na początku brzmiało to jak przesada.

Jedna rzecz, na którą należy zwrócić uwagę: skrypt, który napisaliśmy, sprawdza w plikach, nawet jeśli łańcuch zawodzi gdzieś pomiędzy, aby dać nam szansę na naprawienie go na naszym lokalnym komputerze, sprawdzenie poprawności i ponowne uruchomienie publikowania.

+1

Masz na myśli coś takiego? http://candordeveloper.com/2012/12/12/nuget-package-build-a-solution-of-projects/ –

+0

Nasze pliki NuSpec są nadal edytowane ręcznie, niestety, z niektórymi makrami do automatycznej zamiany wersji. Chodzi mi o to, że automatycznie uruchamiam zależne konfiguracje kompilacji, aktualizuję pakiety NuGet, sprawdzam powstałe zmiany (zwykle pliki .csproj i packages.config) i kontynuuję łańcuch do momentu, aż projekt się powie. –

Powiązane problemy