Pytanie W jaki sposób organizujesz otwarte projekty Visual Studio z zależnościami open-source?


Rozpocząłem projekt MVC4 o otwartym kodzie źródłowym, który używa jakiegoś innego projektu open source jako zależności. Rozwinąłem inny projekt i będę go modyfikował zgodnie z moimi potrzebami. Problemem, który napotykam, jest to, jak zachować te projekty w zależności od siebie, ale utrzymywane osobno. Jednak ludzie, którzy git ciągną mój projekt, również dostaną projekt zależności?

  1. Mogę zatrzasnąć cały powiązany kod z innego projektu do mojego repozytorium, ale w ten sposób nie będę mógł wnieść wkładu do rozwidlenia zależnego projektu. Po prostu zostanę częścią mojego repozytorium. Naprawdę nie chcę tego robić.
  2. Mogę utrzymywać inny projekt całkowicie oddzielnie i kopiować pliki * .dll do mojego projektu. I zatwierdzaj zależne pliki DLL w git. To jest miłe, ale tracę zdolność do rozwijania dwóch projektów jednocześnie, wraz z wkraczaniem w zależny kod podczas debugowania (no może, jeśli nie, kopiowanie plików * .pdb)
  3. Podobnie jak w punkcie 2, mogę budować pakiety nugetów z zależnego projektu i dodawać je do mojego głównego projektu - znowu nie można tak naprawdę rozwijać obu projektów jednocześnie, trzeba zmieniać konteksty.
  4. Z niektórymi magami mamy plik rozwiązania, który łączy projekty z mojego repozytorium iz zależnego repozytorium. Przy każdej kompilacji kopiuj zależne pliki dll do katalogu / lib i zatwierdzaj je. W ten sposób nie trzeba przełączać kontekstów między oddzielnymi projektami. Ale wadą jest to, że inni współpracownicy git ciągną mój projekt, nie są zależni od projektu, a pliki rozwiązań prawdopodobnie zostaną dla nich złamane, ponieważ odwołają się do projektu, którego nie ma w repozytorium.

Jak organizujesz swój kod w tym przypadku?


12
2018-03-12 22:25


pochodzenie


Chcesz skomentować downvote? co ja nie robię dobrze? - trailmax


Odpowiedzi:


Zwykle używam nuget dla wszystkich moich zależności. Kiedy rozwidnę projekt, wdrożę go na nuget i również na źródło symbolu. W ten sposób możesz bez problemu wejść do źródła zależności.

Aby uzyskać więcej informacji na temat źródła symboli i nuget zobacz także: Tworzenie i publikowanie pakietu symboli. Aby włączyć debugowanie źródła symbolu, patrz http://www.symbolsource.org/Public/Home/VisualStudio.

Musisz również pamiętać, aby włączyć Przywracanie pakietu Nuget.

Dzięki temu rozwiązaniu nie można modyfikować kodu źródłowego, ale przynajmniej można go debugować.


5
2018-03-13 11:41



Tak, pakiet nuget z dołączonymi symbolami, prawdopodobnie najlepsza opcja. Źródło symbolu jest interesującym zasobem, nie widziałem go wcześniej. Dzięki! - trailmax


Używam czegoś podobnego w koncepcji do CMake, ale całkowicie w Visual Studio. Istnieje stosunkowo mało znana właściwość plików właściwości, którą można uwzględnić w rozwiązaniach. Pozwala to utworzyć plik zawierający tylko ścieżki do zależności, dołączyć biblioteki, które można i ustawić ścieżki względne, a następnie wymagać od ludzi, aby ustawili odpowiednie ścieżki dla innych zależności, których nie można / nie chcemy uwzględnić.

Przy odrobinie pracy, wychodzi całkiem nieźle i jest bardzo łatwy do zautomatyzowania za pomocą TeamCity i innych podobnych narzędzi (każdy agent kompilacji może ustawić zmienne, aby wskazać, gdzie zachowuje zależności).

W przypadku małych zależności i tych, które zostały zmodyfikowane do pracy z moim projektem, przechowuję archiwum lub luźne pliki w repozytorium i używam pliku właściwości, aby się do nich odwoływać. Inni mają instrukcje, gdzie je znaleźć i jak edytować ścieżki.

Jeśli jesteś zainteresowany takim podejściem, mogę przejść do bardziej szczegółowych informacji. Trzeba było trochę pracy, aby dowiedzieć się, jak pliki własności nie są dobrze udokumentowane, ale działa całkiem zgrabnie.


1
2018-03-15 20:29



które brzmi interesująco. Wszelkie linki do artykułów, w których mogę przeczytać o tych "plikach własności"? - trailmax
Czy o tym mówisz? msdn.microsoft.com/en-us/library/a4xbdz1e(v=vs.110).aspx - trailmax
Tak, to są te. Przygotowałem go z dwoma plikami właściwości: jeden to ścieżki czysto zależne, a ja dostarczam je i wszystkie informacje o mojej wersji przez linię poleceń do większości moich kompilacji (w TeamCity, która działa po prostu za pomocą zmiennych "systemowych"). Drugi to typowe ustawienia projektu dla każdej konfiguracji (ścieżki wyjściowe i podobne). Właściwe użycie zastępczej zmiennej VS w include / library obejmuje ścieżki, a możliwość użycia zmiennych środowiskowych i właściwości w nagłówkach (przekazywanych przez CLI) sprawia, że ​​jest to dość elastyczna i dobrze zorganizowana kompilacja. - ssube
Najpierw trzeba ręcznie edytować niektóre pliki właściwości i skonfigurować załączniki, ale nie jest to skomplikowane, tylko w przybliżeniu i niezbyt udokumentowane. Dla przykładu, jak mam to skonfigurować, sprawdź pliki .sln i .props tutaj. Zauważ, że musisz zaimportować plik właściwości z każdego projektu, aw pliku właściwości ustawić zarówno właściwości (rzeczywiste zmienne), jak i jeśli chcesz ich użyć w nagłówkach, <BuildMacro>na podstawie zmiennej. - ssube
To wygląda świetnie! Pójdę na to, gdy wrócę do projektów. - trailmax


Jeśli nie tworzysz okrągłe zależności, poniżej jest pomysł:

  1. dodaj nowy Class Library projekt o unikalnej nazwie, powiedzmy ClassLibrary1do rozwiązania

  2. w Build strona jego ustawień projektu, config Output path do ścieżki wyjściowej aplikacji

  3. w Build Events stronę, dodaj następujący wiersz do Post-build event command line blok:

    del "$(TargetPath)"
    
  4. powtórz kroki od 1 do 3, ale powiedz coś innego ClassLibrary2i config Output path do ścieżki źródłowej ClassLibrary1

  5. zestaw Project Dependancies z ClassLibrary1, sprawdzić ClassLibrary2

  6. dodaj wszystkie inne projekty jako odniesienie do projektu do ClassLibrary2, opuszczać Copy Local z wartością domyślną true

  7. budować ClassLibrary2 raz, a wszystkie biblioteki DLL znajdują się teraz w ścieżce źródłowej ClassLibrary1

  8. dodaj je do referencji ClassLibrary1 i wyjdź Copy Local z wartością domyślną true

  9. zestaw Project Dependancies wniosku i wszystkich innych projektów, które nie są przyczyną okrągłe zależności, sprawdzić ClassLibrary1

  10. dodaj referencje innych projektów ze ścieżki, w której zostały umieszczone biblioteki DLL ClassLibrary1

  11. zestaw Copy Local wszystkich dodanych bibliotek DLL w innych projektach false

Tak więc projekt ClassLibrary1 być centralną kontrolą zewnętrznych bibliotek twojego rozwiązania. Za każdym razem Rebuild Solution(lub po prostu zbuduj aplikację), ClassLibrary1 kopiuje najnowsze biblioteki DLL do swoich odniesień do folderu wyjściowego aplikacji i usuwa nazwę wygenerowanej przez siebie biblioteki DLL ClassLibrary1.DLL. Aplikacja i zależności w czasie kompilacji lub w środowisku wykonawczym używają tej samej wersji bibliotek DLL, nie trzeba wykonywać dodatkowych instalacji ani sprawdzać poszczególnych wdrożeń.


0
2018-03-15 20:22



Zasadniczo wyjaśniasz, jak zaimplementować część 2 z mojego pytania. Dziękuję, ale część techniczna nie stanowi tutaj problemu. Bardziej interesuje mnie przepływ pracy. Ponieważ w ten sposób muszę przełączać się pomiędzy rozwiązaniami / kontekstami i nie chcę tego robić. - trailmax
Dlaczego nadal musisz się w ten sposób przełączać? - Ken Kin
Ponieważ nie mogę mieć obu projektów w jednym rozwiązaniu VS - spowoduje to rozbicie projektu na inne osoby. - trailmax
@trailmax: To podejście może być stosowane wielokrotnie, co gwarantuje, że nie złamiesz spójności z innymi. Ale ponieważ uważasz, że to nie rozwiąże całkowicie problemu, zamierzam go usunąć. - Ken Kin
Nie, nie usuwaj go. Niektóre osoby mogą uznać to za przydatne w przyszłości. Ale nie jestem pewien, czy całkowicie rozumiem twój ciąg myśli. - trailmax