Zarządzanie wewnętrznymi pakietami NuGet z dostępem do kodu źródłowego

Mamy wiele bibliotek wewnętrznych, które chcielibyśmy udostępniać między projektami wewnątrz firmy. Oto niektóre z wymagań:

źródła biblioteki są przechowywane w repozytoriach oddzielonych od projektów końcowych
projekty końcowe obejmują biblioteki za pośrednictwem NuGet
musi istnieć możliwość łatwego sprawdzenia kodu źródłowego dowolnej biblioteki podczas pracy nad projektem końcowym

Konfigurowanie naszego prywatnego repozytorium NuGet nie stanowi problemu, ale zarządzanie źródłami jest. Staramy się wystawiać źródła za pośrednictwem serwera źródłowego i to trochę działa, ale nie do końca: VS pobierze źródła podczas debugowania kodu zewnętrznego, ale nie podczas próby, aby przejść do definiowania / realizacji. Zasadniczo możesz przejść do kodu źródłowego tylko podczas debugowania, co nie jest nam dokładnie potrzebne.

Tak więc pytania są następujące:

jakie istnieją sposoby zapewnienia dostępu do kodu źródłowego bibliotek wewnętrznych bez konieczności posiadania kodu w tym samym repozytorium / rozwiązaniu
czy istnieje sposób na skonfigurowanie kombinacji Symbol server / NuGet, aby VS używał symboli do nawigacji, a nie tylko do debugowania?

Korzystanie z ReSharper / innych dodatków jest opcją.

c# source-code closed-source nuget

— Dyppl
źródło

Stwierdziliśmy, że wykorzystanie Nuget do zarządzania projektami wewnętrznymi nie jest optymalne; w końcu zgarnęliśmy go na rzecz referencji projektu i DLL. Chciałbym usłyszeć od kogoś, kto był w stanie sprawić, by to zadziałało.

— Robert Harvey

Czy skonfigurowałeś również serwer symboli dla plików pdb, które odpowiadają dllom zawartym w twoich pakietach NuGet?

— RubberDuck,

Mamy dokładnie taką samą konfigurację w moim obecnym miejscu pracy. Serwer NuGet (zawiera biblioteki DLL bez PDB) oraz serwer symboli (zawiera biblioteki DLL, PDB i źródła). Mamy również ten sam problem (źródła i PDB pobierane tylko podczas debugowania). @RobertHarvey: Menedżer pakietów NuGet jest słabym klientem NuGet. Nie rozróżnia zależności bezpośrednich i przejściowych i wymaga głupich działań „konsolidujących”. Przeszliśmy na Paket i odtąd nie oglądaliśmy się za siebie. Sprawiło, że zarządzanie pakietami było rozsądne i znośne, granicząc z przyjemnością.

— Allon Guralnek

Muszę zapytać - choć nie sądzę, że jest to nieuzasadniony wymóg - dlaczego musisz mieć możliwość przeglądania pakietów wspólnych / wspólnych? Teoretycznie przynajmniej powinny to być udokumentowane czarne skrzynki, a potrzeba zajrzenia do środka powinna być wyjątkiem, a nie normą. W każdym razie są one dostępne w repozytorium źródłowym i dlatego pobranie rozwiązania do sprawdzenia powinno być banalnie trywialne. Widzę wiele powodów, dla których ta lub niektóre jej części mogą nie być całkowicie prawdą, ale wciąż warto o to zapytać.

— Murph,

@Murph - nie jestem OP, ale z mojego doświadczenia wynika, że dokumentacja nigdy nie oddaje szczegółów, których chcę. Czy muszę wyczyścić ten stan, czy też odbiorca pomocy? Co to właściwie ucieka? Czym różnią się te przeciążenia? Czy te podmioty popierają równość, a jeśli tak, to w oparciu o co? Jaka jest przybliżona złożoność tego połączenia? Jedyną szczegółową dokumentacją, którą warto mieć, jest (czyste) źródło, ponieważ zawsze i często będą rzeczy, których autor nigdy nie rozważał, ale które są dla ciebie ważne. Co gorsza, złożona dokumentacja nieuchronnie zawiera błędy i staje się nieaktualna.

— Eamon Nerbonne

Odpowiedzi:

To, co powinno działać, to po prostu sprawdzenie kodu źródłowego pakietu NuGet i otwarcie rozwiązania w osobnej instancji programu Visual Studio.

Visual Studio ma fajną sztuczkę przełączania między kodem w otwartych instancjach poprzez wypracowanie tego, do czego się odwołujesz. Pierwszy raz, kiedy mi się to zdarzyło, kiedy debugowałem, było objawieniem.

Głównym problemem, z jakim się stykasz, jest upewnienie się, że wypisany kod dla pakietu zależnego reprezentuje tę samą wersję, co odniesienie NuGet w głównym projekcie. Nie stanowi to problemu, jeśli będziesz przestrzegać zasad ciągłego budowania w oparciu o najnowszą wersję pakietu.

Inną zaletą tego podejścia jest to, że jeśli pakiet wymaga zmiany, możesz wprowadzić zmiany tam i teraz.

— Stewart Ritchie
źródło

Czy możesz podać dodatkowe informacje na temat tego, jak to działa? To nie działa tak, jak dla mnie opisałeś. Czy musisz dołączyć PDB do paczki? Jakieś dodatkowe sztuczki?

— Dyppl

-1

Może możesz użyć https://github.com/GitTools/GitLink . Dodaje link w pliku pdb wskazujący na repozytorium, dzięki czemu Visual Studio pobierze stamtąd kod źródłowy - a następnie wystarczy dołączyć plik pdb do pakietu nuspec i nie będzie potrzebował serwera źródłowego.

— Jesper Balle
źródło

Czy to działa poza debugowaniem? Nie wygląda tak.

— Dyppl,

-1

Nie jest to więc idealne rozwiązanie, ale wspominasz, że możesz opcjonalnie użyć Resharper; Dzięki dotPeek i resharper możesz przejść do demontażu oryginalnego kodu, tego używam w pracy, gdzie mamy podobną konfigurację do twojej.

Uważam kombinację serwera symboli, o którym wspomniałeś, i przeglądanie dezasemblacji zwykle wystarcza, aby dowiedzieć się, co się dzieje.

Mam nadzieję, że to pomaga.

Edycja: Po ponownym przeczytaniu pytania zdaję sobie sprawę, że specjalnie poprosiłeś o możliwość przeglądania kodu źródłowego, co nie jest prawdą. Niemniej jednak mam nadzieję, że komuś się przyda.

— BaronVonDrew
źródło