Это проблема, которая не имеет четкого ответа, но ...
Есть два пути, по которым вы можете пойти.Сильно связанная система или слабо связанная система.
Для сильно связанной системы я могу предложить два каталога для двоичных файлов: сторонний каталог и каталог, в котором находятся библиотеки DLL, которые ваша компания создает, на которые могут ссылаться другие разработчики.Сторонние библиотеки DLL (за пределами вашей компании) должны находиться в системе контроля версий, чтобы все разработчики ссылались на одни и те же версии сторонних библиотек DLL из одного и того же местоположения, что позволяет избежать несоответствий машины разработчика и проблем с установкой стороннего программного обеспечения на каждую машину.На внутренние библиотеки DLL нельзя ссылаться в системе контроля версий, и они должны быть собраны на каждом компьютере разработчика с помощью автоматизированного пакетного файла сборки или подобного.На шаге пост сборки вы можете скопировать их все в один и тот же каталог, и пока разработчики получают последние версии системы управления версиями и сборки, у всех есть одинаковые DLL из вашей компании.
Например, получить последнюю версию, сборку(используя пакетный файл для сборки всех необходимых проектов), а затем в качестве шага после сборки скопируйте вывод в общий.Теперь все ваши другие проекты могут ссылаться на обычные DLL-библиотеки Compnay и сторонние DLL-библиотеки из одного и того же местоположения, и все они согласованы.
Проблема в том, что ссылки тесно связаны между собой, поэтому изменения иногда могут быть проблематичными, если нетправильно сообщен.
В слабосвязанной системе используется такая структура, как MEF (Managed Extensibility Framework), и ваши компоненты ссылаются на "Contract DLL", которая определяет интерфейсы для ваших компонентов.Проект ссылается на интерфейсные или контрактные библиотеки DLL и на самом деле не заботится о реализации, а затем MEF управляет плагином для вас.
В этом случае вы ссылаетесь на интерфейсную библиотеку DLL, а не на реальную библиотеку DLL, которая ее реализует.
Например, скажем, у меня есть интерфейс ILog с методом LogMessage.
private ILog _logger;
_logger.LogMessage();
Итак, в сильно связанном случае: Action.DLL напрямую ссылается на Logger.DLL.
В слабосвязанном случае Action.DLL ссылается на ILog.DLL (только интерфейс).Logger.DLL реализует ILog.DLL.Но Action.DLL не имеет прямой ссылки на Logger.DLL.
Теперь я могу иметь любое количество библиотек DLL, которые влияют на интерфейс ILog, но Action.DLL не ссылается на них напрямую.Это довольно круто, и одна из самых захватывающих функций MEF и слабой связи в целом - способность не иметь зависимостей.
Как вы решите пойти, в любом случае приемлемо, я думаю, что слабо связанная идея подходитВаш сценарий лучший, так как командам просто нужно знать контракты в сравнении с фактическими реализациями.
У меня не было бы одной крупной контрактной DLL, я бы попытался разбить интерфейсы на логические группировки.Например, ведение журнала выглядит как интерфейс служебной программы Utility, поэтому я хотел бы создать DLL-библиотеку контрактов Utility с интерфейсом ILog.Как это разделить, зависит от того, что вы пытаетесь сделать.Или каждый интерфейс может быть контрактной DLL, но, возможно, это немного экстремально.