deklarowanie pakietów nuget, które zależą od siebie w jednym rozwiązaniu.

Question

Mamy rozwiązanie z wieloma projektami i mniej lub bardziej złożonym grafem zależności między tymi projektami. Teraz każdy z tych projektów powinien stać się jego własnym pakietem nuget, a wykres zależności pakietów nuget powinien odzwierciedlać projekt.

Mam dwa pytania:

1. Czy to możliwe, aby to osiągnąć, zachowując jednocześnie wszystkie projekty w tym samym roztworze? Jeśli tak to jak?
2. Czy zalecane jest utrzymanie wszystkich projektów w tym samym rozwiązaniu? Jakie byłoby wspólne/"najlepsze praktyki" podejście do tego?

Answer 1

Sytuacja w naszym projekcie jest taki sam i wzięliśmy następujące podejście:

Pierwszym krokiem jest stworzenie nuspec plików definiujących swoje pakiety. Wszystkie pliki te umieściliśmy w folderze o nazwie ".nuspec", który znajduje się w katalogu głównym rozwiązania. Pliki Nuspec są dodawane do rozwiązania w folderze rozwiązania o nazwie ".nuspec".

Samo rozwiązanie ma globalny plik AssemblyInfo zawierający informacje o wersjach, a także niektóre informacje dotyczące praw autorskich - w skrócie wszystkie informacje, które są wspólne dla naszych projektów. Każdy projekt ma następnie swoje własne informacje o montażu, dodając informacje specyficzne dla każdego projektu.

Pliki nuspec nie zawierają wersji. Zamiast tego używamy $(version) jako zastępczy tam:

<?xml version="1.0" encoding="utf-16"?> 
<package xmlns="http://schemas.microsoft.com/packaging/2011/08/nuspec.xsd"> 
    <metadata> 
    <id>MyCompany.MyProduct.Server.DataAccess</id> 
    <version>$(Version)</version> 
    <authors>MyCompany</authors> 
    <projectUrl>http://example.com/myProduct.html</projectUrl> 
    <iconUrl>http://example.com/myProduct.icon.png</iconUrl> 
    <requireLicenseAcceptance>false</requireLicenseAcceptance> 
    <description>Some description goes here.</description> 
    <summary>The summary goes here</summary> 
    <copyright>Copyright © MyCompany 2015</copyright> 
    <language>en-US</language> 
    <dependencies> 
     <dependency id="MyCompany.MyProduct.Common" version="$(Version)" /> 
     <dependency id="MyCompany.MyProduct.Server" version="$(Version)" /> 
    </dependencies> 
    </metadata> 
    <files> 
    <file src="path\to\MyCompany.MyProduct.Server.DataAccess.dll" target="lib\net45\MyCompany.MyProduct.Server.DataAccess.dll" /> 
    </files> 
</package> 

(. Oczywiście Zależności może mieć zależności siebie Komponent serwera może odwoływać się do składnika rejestrowania na przykład.)

Początkowo stworzyliśmy aplikację konsoli czytanie wersji rozwiązania z globalnego pliku AssemblyInfo i analizowanie go do wszystkich plików Nuspec przed utworzeniem i opublikowaniem pakietów.

Aplikacja konsolowa działała dobrze, ale była nieco uciążliwa w utrzymaniu w środowisku TFS z włączoną ciągłą integracją. Tak więc zdefiniowaliśmy niestandardowy szablon kompilacji TFS wykonujący tę pracę.Jedyne, co musimy teraz zrobić, aby stworzyć zestaw pakietów nuget dla wszystkich naszych projektów, to wyzwolić kompilację TFS.

Takie podejście ma tę zaletę, że wszystkie pakiety mają tę samą wersję i dzięki temu dobrze ze sobą współpracują. To podejście ma tę wadę, że wszystkie pakiety mają tę samą wersję i nie mogą być wydawane niezależnie.

Wybraliśmy to podejście, ponieważ uniemożliwiło nam wytwarzanie konglomeratu źle zintegrowanych komponentów. Nasze projekty dostarczają małych ram, które są używane do tworzenia małych aplikacji LOB, które są bardzo podobne. Ze względu na to, że dostarczamy framework w zestawie różnych pakietów, programiści mogą wybrać, które pakiety rzeczywiście potrzebują, a następnie zainstalować tylko te. Jeśli deweloper zdecyduje się dodać brakującą funkcjonalność później, po prostu instaluje odpowiednie pakiety, które mają tę samą wersję, co te już zainstalowane. Dzięki temu nie musisz się martwić o kompatybilność.

Answer 2

Tak, można "prawdopodobnie" wykonać tę pracę. Mówię najprawdopodobniej dlatego, że go nie wypróbowałem, ale podchodzę do tego z czymś takim: https://www.nuget.org/packages/CreateNewNuGetPackageFromProjectAfterEachBuild/ z ręcznym nuspeciem definiującym Twoje referencje zadziała. Jeśli chcesz naprawdę się spodobać, możesz napisać kod Roslyn po kompilacji, aby przeanalizować zależności projektu i zbudować drzewo zależności nugetu. To powiedziawszy, nie rób tego, w niebanalnym rozwiązaniu, prawie na pewno szybko stanie się ręcznym i łamliwym.

W ostatecznym rozrachunku lepiej jest po prostu przełamać swoje rozwiązanie - stworzyć rozwiązanie na pakiet Nuget i pobrać zależności za pomocą samego Nuget. Zakładając, że masz serwer build/CI, powinno to być dość trywialne. Po prostu uruchom własne repozytorium Nuget i opublikuj artefakty kompilacji, gdy tylko zostaną zbudowane - w ten sposób twoje projekty zależne wyciągną najnowszy pakiet, który TYLKO zbudowałeś. Będziesz chciał, aby twój proces kompilacji odświeżał Nuget za każdym razem i możesz użyć standardowej komendy nuget spec jako kroku po kompilacji. Jako miłą premię zmusi wszystkich pracujących nad kodem do myślenia o zależnościach podczas wprowadzania zmian.