To jest problem, że nie ma jednoznacznej odpowiedzi, ale ...
Istnieją dwie drogi, które można podjąć. Silnie sprzężony system lub luźno sprzężony system.
Dla systemu silnie sprzężonego mogę zaproponować dwa katalogi dla plików binarnych: katalog stron trzecich oraz katalog zawierający pliki DLL, które kompiluje firma, do których inni deweloperzy mogą się odwoływać. Zewnętrzne biblioteki DLL (spoza firmy) powinny znajdować się w źródłowej kontroli, aby wszyscy programiści odnosili się do tych samych wersji bibliotek DLL innych firm z tej samej lokalizacji, co pozwala uniknąć niespójności między programistami a problemami związanymi z instalowaniem oprogramowania stron trzecich na każdym komputerze. Domowe biblioteki DLL nie powinny być przywoływane w źródłowej kontroli i powinny być budowane na każdej maszynie programistycznej za pośrednictwem zautomatyzowanego pliku wsadowego budowania lub podobnego. W kroku budowania postu możesz skopiować je wszystkie do tego samego katalogu i dopóki programiści otrzymają najnowszą kontrolę i kompilację kodu źródłowego, każdy ma te same pliki DLL z twojej firmy.
Na przykład, pobierz najnowsze, skompiluj (używając pliku wsadowego, aby zbudować wszystkie potrzebne projekty), a następnie jako krok budowania postu skopiuj dane wyjściowe do wspólnego. Teraz wszystkie inne projekty mogą odwoływać się do wspólnych bibliotek DLL oraz bibliotek DLL innych firm z tej samej lokalizacji i wszyscy są konsekwentni.
Problem polega na tym, że odniesienia są silnie sprzężone, więc zmiany mogą czasami być problematyczne, jeśli nie zostaną poprawnie przekazane.
Luźno powiązany system korzysta z frameworka, takiego jak MEF (Managed Extensibility Framework), a odniesienia do komponentów "Contract DLL" definiują interfejsy dla komponentów.Projekt odwołuje się do interfejsu lub kontraktowych bibliotek DLL i nie obchodzi go implementacja, a MEF zarządza wtyczką.
W tym przypadku użytkownik odwołuje się do interfejsu DLL, ale nie do rzeczywistej biblioteki DLL, która implementuje.
Załóżmy na przykład, że mam interfejs o nazwie ILog z metodą o nazwie LogMessage.
private ILog _logger;
_logger.LogMessage();
Tak więc, w przypadku silnie powiązanego: Action.DLL bezpośrednio odwołuje się do Logger.DLL.
W luźno powiązanym przypadku Action.DLL odwołuje się do ILog.DLL (tylko interfejs). Logger.DLL implementuje ILog.DLL. Ale Action.DLL nie ma bezpośredniego odniesienia do Logger.DLL.
Teraz mogę mieć dowolną liczbę bibliotek DLL, które implikują interfejs ILog, ale Action.DLL nie odwołuje się do nich bezpośrednio. To całkiem fajna i jedna z bardziej ekscytujących cech MEF i luźnego sprzężenia w ogóle, możliwość nie posiadania zależności.
W jaki sposób zdecydujesz się iść, tak czy owak jest do zaakceptowania, myślę, że luźno powiązany pomysł pasuje do Twojego scenariusza najlepiej, ponieważ zespoły musiałyby znać tylko kontrakty w porównaniu do rzeczywistych wdrożeń.
Nie miałbym jednej potężnej biblioteki DLL, spróbowałbym rozbić interfejsy na logiczne grupy. Na przykład rejestrowanie wydaje się interakcją typu Utility, więc utworzę DLL kontraktu Utility z interfejsem ILog. Sposób podziału jest zależny od tego, co próbujesz zrobić. Lub każdy interfejs może być DLL umowy, ale może to trochę ekstremalne.
Posiadam interfejsy stabilne dla zestawu SDK. Jeśli potrzebujesz zmienić interfejs, opracuj nowy i wycofaj stary, ale wdrażaj go przez pewien czas. Chciałbym, aby każdy projekt wtyczki był zbudowany na najnowszym SDK. Zajrzałbym do MEF lub lepszego dla mnie narzędzia DI, takiego jak Autofac. – kenny
Prawdopodobnie wolałbym podejście "praca z daną, stabilną wersją" - a dzięki NuGet można łatwo spakować swoje SDK i inne pliki wsparcia do pakietów NuGet, które można łatwo zainstalować w Visual Studio, a także starannie zaktualizować! –
Czy mogę wdrażać pakiety NuGet wewnątrz naszej firmy? co oznacza, że inni użytkownicy mogą pobierać najnowsze aktualizacje bez publicznego ujawniania naszego kodu? –