Bezbolesny rozwój lokalny, a także nawiązywanie do pakietów NuGet

Question

Bezbolesny rozwój lokalny, a także nawiązywanie do pakietów NuGet

Próbuję opublikować i zużyć wersjonowane pakiety NuGet bibliotek klas, unikając przy tym bólów głowy dla lokalnego rozwoju. Oto przykładowy układ rozwiązania Visual Studio:

| Libraries
  | LibraryA
  | LibraryB
  | LibraryC
| Applications
  | ApplicationD
  | ApplicationE

Jest to jedno rozwiązanie zawierające zarówno współdzielone biblioteki klas, jak i wiele aplikacji. Obecnie odwołania do bibliotek klas przez aplikacje są lokalnymi odniesieniami do rozwiązań.

Chciałbym opublikować biblioteki (A, B, C) jako wersjonowane pakiety NuGet które następnie są przywoływane przez aplikacje w razie potrzeby (D,E). Dzięki temu zmiana biblioteki współdzielonej może być niezależna od aktualizacji do wdrożonej aplikacji. Bez tego zmiana jednej biblioteki mogłaby spowodować zmianę binariów w kilkunastu lub więcej aplikacjach, z których wszystkie technicznie wymagałyby przetestowania. Jest to niepożądane, a wersjonowanie z NuGet naprawia to.

Powiedzmy jednak, że chcę jednocześnie aktualizować zawartość LibraryA i ApplicationD. Aby to zrobić po przejściu na NuGet, będę musiał wprowadzić zmiany w LibraryA, zatwierdzić je, poczekać na utworzenie pakietu, powiedzieć ApplicationD, aby zaktualizować jego odniesienie do LibraryA, a następnie przetestować lub rozwinąć w ApplicationD. Jest to o wiele bardziej skomplikowane niż zwykła praca z obydwoma jednocześnie przy użyciu lokalnych odniesień do rozwiązań.

Jaki jest lepszy sposób na uzyskanie zarówno solidności wersjonowanych pakietów NuGet dla moich bibliotek współdzielonych klas przy jednoczesnym zachowaniu rozwój prosty, nawet jeśli obejmuje wiele projektów i aplikacji? Jedyne inne rozwiązania, które znalazłem, wiążą się ze zbyt dużym obciążeniem lub bólem głowy, takie jak konieczność ciągłej zmiany odniesień do aplikacji między pakietem NuGet a lokalnym projektem.

EDIT: aby wyjaśnić przesłankę, to pytanie zakłada, że:

Shared biblioteki będą się zmieniać z nietrywialną częstotliwością
aplikacje mogą odwoływać się do różnych wersji bibliotek współdzielonych

34

c#visual-studio nuget visual-studio-2013 nuget-package

Author: jmsb, 2014-12-30

Source

3 answers

Chociaż wymaga to trochę pracy, możliwe jest ręczne edytowanie .pliki csproj w celu skonfigurowania odwołań warunkowych poprzez dodanie atrybutu Condition do odpowiednich odwołań.

EDIT przeniosłem te warunki do ItemGroups, ponieważ wygląda na to, że tak działa mój wspomniany kod produkcyjny i wspomniano o tym, że jest to możliwy problem w VS 2013.

<ItemGroup Condition="'$(Configuration)' == 'Debug Local'">
    <!-- Library A reference as generated by VS for an in-solution reference, children unmodified -->
    <ProjectReference>...
</ItemGroup>

<ItemGroup Condition="'$(Configuration)' == 'Debug NuGet'">
    <!-- Library A reference as generated by NuGet, child nodes unmodified --> 
    <Reference Include="LibraryA">...
</ItemGroup>

Pozwoli to na konfigurację w projektach D & E "Debug NuGet" vs. "Debug Local", które odwołują się do bibliotek w różny sposób. Jeśli Następnie masz wiele plików rozwiązań, które mają swoje konfiguracje mapowane do odpowiednich konfiguracji w ramach projektów, użytkownik końcowy nigdy nie zobaczy więcej niż "Debug" i "Release" dla większości operacji, ponieważ są to konfiguracje rozwiązania i musiałby tylko otworzyć pełne rozwiązanie do edycji projektów A, B i C.

Jeśli chodzi o usunięcie projektów A, B I C, to można je ustawić pod folder oznaczony jako subrepo (zakładając, że używasz SCM, który to obsługuje, na przykład Git). Większość użytkowników nigdy nie musiałaby wyciągać subrepo, ponieważ nie mają dostępu do projektów ABC, a zamiast tego pobierają z NuGet.

Jeśli chodzi o utrzymanie, mogę zagwarantować, że VS nie będzie edytował referencji warunkowych i będzie je szanował podczas kompilacji-przeszedłem zarówno VS 2010, jak i 2013 ( EDIT : Wersja Professional, choć zagłębiłem się w to samo z express) z tymi samymi warunkowymi projektami referencyjnymi w pracy. Należy pamiętać, że w VS odniesienia mogą być wykonane w wersji-agnostic, czyniąc NuGet jedynym miejscem, z którego wersja musi być utrzymywana, i można to zrobić jak każdy inny pakiet NuGet. Mam nadzieję, że nie testowałem, czy NuGet będzie walczył z referencjami warunkowymi.

EDIT można również zauważyć, że odwołania warunkowe mogą powodować ostrzeżenia o brakujących bibliotekach DLL, ale w rzeczywistości nie utrudniają kompilacji albo uciekać.

17

Author: David,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-12-30 20:10:12

Wiem, że to jest 2-letni post, ale po prostu znalazłem go w obliczu tej samej sytuacji. Znalazłem to również dla VS2015, jestem w trakcie testowania. Wrócę i dostosuję odpowiedź.

Https://marketplace.visualstudio.com/items?itemName=RicoSuter.NuGetReferenceSwitcherforVisualStudio2015

8

Author: JayR,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-09 14:25:42

score 3 · Accepted Answer

Niestety, naprawdę nie ma sposobu, aby mieć to, co najlepsze z obu światów. Wewnętrznie w mojej firmie nieco go złagodziliśmy dzięki szybkiemu procesowi budowania/wdrażania, który przeciwdziała większości obciążeń, zawsze odwołując się do pakietu NuGet. Zasadniczo wszystkie nasze aplikacje używają innej wersji tej samej biblioteki hostowanej w lokalnym repozytorium NuGet. Ponieważ używamy własnego oprogramowania do budowania, wdrażania i hostowania pakietów, bardzo szybko aktualizujemy bibliotekę, a następnie ją aktualizujemy Pakiet NuGet w innym rozwiązaniu. Zasadniczo najszybszy przepływ pracy, jaki znaleźliśmy, to:

dokonaj zmian w bibliotece
automatycznie buduj i wdrażaj wersję biblioteki zwiększoną o 1 do wewnętrznego kanału NuGet
Aktualizacja pakietu NuGet w aplikacji konsumenckiej

Cały proces od check - in do aktualizacji projektu trwa około 3 minut. Repozytorium NuGet posiada również serwer symbol/source, który ogromnie pomaga w debugowaniu.