W jaki sposób udostępniasz zewnętrzne zależności między rozwiązaniami Visual Studio?

Question

Mam tło Java, więc jestem przyzwyczajony do tego, że Maven zajmuje się problemem związanym z pobieraniem i aktualizowaniem zależności. Ale w środowisku .NET nie znalazłem jeszcze dobrego sposobu na zarządzanie wszystkimi tymi zewnętrznymi zależnościami.

Głównym problemem jest to, że masowo produkować rozwiązania i wszystkie one zależą od tych samych dll trzeciej strony. Ale nie chcę utrzymywać oddzielnych kopii każdego komponentu w ramach każdego rozwiązania. Potrzebuję więc sposobu na połączenie wszystkich różnych rozwiązań z tym samym zestawem bibliotek dll.

Zdałem sobie sprawę, że jednym z rozwiązań może być włączenie bibliotek zewnętrznych do "projektu bibliotecznego", który jest zawarty we wszystkich rozwiązaniach, i niech inne projekty odwołują się do nich za jego pośrednictwem. (Lub po prostu pamiętaj, aby odwołać się do zewnętrznych bibliotek dll z tego samego miejsca dla wszystkich projektów.)

Ale czy są jakieś lepsze sposoby na zrobienie tego? (Najlepiej za pomocą wtyczki do Visual Studio.)

Spojrzałem na Visual Studio Dependency Manager i wygląda na to, że idealnie pasuje, ale czy ktoś próbował go naprawdę? Widziałem także porty .NET w Maven, ale niestety nie byłem pod wrażeniem ich statusu. (Ale proszę śmiało polecić każdemu, jeśli uważasz, że powinienem spróbować jeszcze raz.)

Jaki byłby najmądrzejszy sposób rozwiązania tego problemu?

Aktualizacja:

zdałem sobie sprawę, że muszę wyjaśnić, co mam na myśli z linkami do tego samego zestawu dll.

Jedną z rzeczy, które staram się tutaj osiągnąć, jest uniknięcie sytuacji, w której różne rozwiązania odnoszą się do różnych wersji każdego z komponentów. Jeśli zaktualizuję komponent do nowej wersji, powinien on zostać zaktualizowany dla wszystkich rozwiązań podczas następnej kompilacji. Zmusiłoby to mnie do upewnienia się, że wszystkie rozwiązania są aktualne z najnowszymi komponentami.

Aktualizacja 2: Należy pamiętać, że jest to stara pytanie zadane przed narzędziami jak NuGet lub OpenWrap istniał. Jeśli ktoś chce bardziej aktualny, proszę śmiało, a ja zmienię zaakceptowaną odpowiedź.

Answer 1

1. Znajdź miejsce do przechowywania złożeń. Na przykład przechowuję plik.zespoły bazowa tak:

   • <branch> \ NetFX \ 2,0527 \ *
   • <branch> \ NetFX \ 3,0 \ *
   • <branch> \ NetFX \ 3,5 \ *
   • <branch> \ NetFX \ Silverlight 2 \ *
   • <branch> \ NetFX \ Silverlight 3 \ *

2. Użyj właściwości ReferencePath w MSBuild (lub AdditionalReferencePath w Build Team), aby wskazać swoje projekty w odpowiednich ścieżkach. Dla uproszczenia i łatwej konserwacji mam 1 * plik .targets, który wie o każdym takim katalogu; wszystkie moje projekty Zaimportuj ten plik.

3. Upewnij się, że strategia kontroli wersji (rozgałęzienia, łączenia, lokalne < -> odwzorowania serwerów) utrzymuje względne ścieżki między Twoimi projektami & Stała ścieżek referencyjnych.

EDIT

W odpowiedzi na aktualizację w pytaniu, dodam jeszcze jeden krok:

4) Upewnij się, że każde odniesienie montaż w każdym pliku projektu wykorzystuje pełną .Net silną nazwę i nic więcej,.

Źle:

<Reference Include="Microsoft.SqlServer.Smo"> 
    <SpecificVersion`>False</SpecificVersion> 
    <HintPath>..\..\..\..\..\..\..\Program Files (x86)\Microsoft SQL Server\100\Shared\Microsoft.SqlServer.Smo.dll</HintPath> 
</Reference> 

Dobre: ​​

<Reference Include="Microsoft.SqlServer.Smo, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL" /> 

Zalety ostatnim formacie:

• Korzystanie z HintPath w środowisku rozwoju współpracy nieuchronnie doprowadzi do sytuacji, gdzie „to działa dla mnie ", ale nie dla innych. Zwłaszcza twój serwer kompilacji. Pominięcie go zmusza cię do uzyskania poprawnych ścieżek referencyjnych lub nie zostanie skompilowany.
• Używanie słabej nazwy zachęca do "piekła DLL". Gdy użyjesz silnych nazw, bezpieczne będzie posiadanie wielu wersji tego samego zestawu w ścieżkach referencyjnych, ponieważ linker będzie ładował tylko te, które pasują do każdego kryterium. Ponadto, jeśli zdecydujesz się zaktualizować niektóre złożeń w miejscu (zamiast dodawać kopie), zostaniesz powiadomiony o wszelkich zmianach łamania w czasie kompilacji zamiast , gdy tylko pojawią się błędy.

Answer 2

zwykle mają oddzielną strukturę folderów w sprawie kontroli źródłowego extrenal lub wewnętrznymi zależnościami, a te filders mają zespoły według zbudować lub numer wersji np

public \ Zewnętrzna \ biblioteki \ NUnit \ 2.6 \

lub

Public \ wewnętrzne \ biblioteki \ Logger \ 5.4.312 \

i wewnątrz rozwiązania wszystkich projektów, które muszą korzystać z któregokolwiek z zależnościami tylko dodaje odniesienie do tego assem w publicznych folderach wewnętrznych lub zewnętrznych.

Answer 3

Dodając do tego, co wszyscy inni mówią, że w zasadzie sprowadza się do dwóch rzeczy:

1. Upewniwszy się, że wszyscy deweloperzy mają te same wersje bibliotek zewnętrznych
2. Upewniwszy się, że wszyscy deweloperzy mają biblioteki zewnętrzne znajdujące się w tym samym miejscu (przynajmniej w stosunku do kodu źródłowego)

Jak zauważa Richard Berg, można użyć ReferencePath i/lub Additi onalReferencePath, aby pomóc w rozwiązaniu # 2. Jeśli używasz msbuild w procesie kompilacji (w naszym przypadku używamy CruiseControl zamiast MS Team Build), możesz także przekazać do niego ReferencePath w linii poleceń. Aby rozwiązać # 1, znalazłem svn:externals, aby było przydatne (jeśli używasz SVN).

Moje doświadczenie z Mavenem polega na tym, że jest to przesada w większości zastosowań.