Utrzymywanie odniesień do zestawów .NET wspólnych dla wielu projektów

Question

Moi koledzy i ja zastanawialiśmy się, jak najlepiej to zrobić od dłuższego czasu: jaki jest dobry/standardowy sposób na utrzymanie zespołów .NET, do których odwołuje się wiele projektów? Rozwiążę trochę:

Powiedzmy, że masz projekty A, B i C. Mogą one być w tym samym lub różnych rozwiązaniach, tak naprawdę nie ma znaczenia. Masz również projekty D i E, które generują biblioteki DLL dla A/B/C w celu odniesienia. Na dobrą sprawę możemy rzucić w F-montażu innej firmy, dla którego mamy tylko bare DLL. Gdzie jest dobrym miejscem, aby umieścić zespoły z D i E, oraz plik z F, tak aby jak najwięcej z poniższych rzeczy wystąpić:

• Aktualizacje do D i/lub E nie muszą być ręcznie odświeżane/zmieniane w projektach A, B lub C;
• Projekty A, B i C można pobrać na nową maszynę za pomocą kontroli źródła i skompilować z najmniejszą ilością kłopotów; i
• Wyjścia DLL dla D i E oraz plik dla F są zlokalizowane mniej więcej centralnie.

Prawdopodobnie pytam za dużo, ale czy istnieje jakiś znany sposób na wykonanie większości/wszystkiego? Zastanawiamy się nad tym od dłuższego czasu.

Answer 1

Jednym (prawdopodobnie nie optymalnym) rozwiązaniem jest użycie Maven do zarządzania zależnościami.

Zobacz ten tutorial: Using Maven to manage .NET projects

Answer 2

Poniższy powinno wystarczyć myślę:

1) mają folder zwalniającą gdzie dll strona trzecia będzie obecna.
2) Dodaj również skrypt budowania postów, aby skopiować złozenia D.dll i E.dll do folderu wydania po pomyślnej kompilacji.
3) Projekty A, B i C odwoływałyby się do D.dll i E.dll z folderów wydania.

Również nie ma sensu dodawanie D.dll i E.dll z folderu wydania do kontroli kodu źródłowego. Mechanizm budowania powinien być automatycznie w stanie obsłużyć to.