Есть ли способ, чтобы несколько приложений ссылались на глобальный проект, который имеет другие ссылки на проекты

Question

После долгих поисков мне кажется, что я не могу найти ответ на свою проблему.Обычно я нахожу, что это означает, что это несуществующий или неправильный подход, но я думаю, что это стоит того, чтобы в Интернете все же был ответ.

По сути, у нас есть 4 приложения, ссылающихся на 5 разных «исходных» проектов.Таким образом, сценарий таков: когда мы добавляем 5-е приложение (например), нам нужно будет создать ссылки на проекты для 5 других проектов, поскольку приложение требует их вывода.

Это не сложная задача, потому чтоколичество проектов невелико, но это заставило нас задуматься.Что если вы могли бы создать один проект, может быть, под названием Libs или что-то еще, ссылаться на все 5 проектов в этом проекте, и тогда приложения должны ссылаться только на Libs.Идея кажется классной, но я не знаю, сработает ли она, потому что когда вы создаете ссылку на проект, она указывает на один выход libs libs.dll.

Так что, на самом деле, задать вопрос, возможно ли это,и если да, то как это можно сделать?В настоящее время наличие ссылок на Libs на другие «исходные» проекты, а затем ссылки на приложения на проект Lib не работает, поскольку в нем говорится, что отсутствуют сборки.

И просто рассмотрим, как это было создано.5 исходных проектов находятся в нескольких разных решениях, поэтому единственной утомительной частью этого подхода является «добавить существующий проект» при первоначальном запуске решения приложения.

Answer 1

Способ управления такими вещами в моей организации заключается в создании пакета NuGet для каждого из этих общих «исходных» проектов (например, в нашем случае у нас есть библиотека регистрации ошибок, библиотека утилит XML, сделанный на заказ HTTP-клиент, и другие).Они публикуются по нашему частному URL-адресу фида NuGet (размещенному в DevOps Azure, но вы можете просто использовать стандартный файловый ресурс Windows при необходимости), чтобы наши разработчики могли использовать их в своих приложениях.

Это имеет некоторые явные преимущества перед вашим подходом:

1) Зависимости - это, кажется, наиболее актуально для вашего вопроса.Если проект, из которого вы создали пакет NuGet, зависит от любых других пакетов NuGet (общедоступных или других из нашего частного канала), то, когда кто-то устанавливает этот пакет в свой проект, он автоматически устанавливает все остальные пакеты, от которых зависит.

Таким образом, в вашем случае вы могли бы создать пакет оболочки "libs", который не доставляет сам контент, но имеет зависимости от всех остальных ваших пакетов, в результате чего они устанавливаются автоматически.В нашем случае у нас есть несколько случаев зависимости (например, «базовый» пакет регистрации ошибок, на который опираются модули обработки ошибок, адаптированные к различным типам приложений, например, MVC, Web API, Windows Services), и он работает очень хорошо.

2) Обновления и обслуживание.В вашем сценарии, если вы вносите критические изменения в один из ваших «исходных» проектов, то, поскольку у вас есть прямая ссылка на проект, объявленная в Visual Studio, любой проект, который ссылается на исходный, должен будет внести соответствующие изменения, чтобы справиться с обновлениями.в исходный проект, прежде чем вы сможете перекомпилировать его и выполнить любые изменения функций, которые вы пытаетесь достичь.Это может быть болью и несвоевременной проблемой, особенно в случае серьезных обновлений.Однако, если вместо этого вы установите пакет NuGet, содержащий эти функции, разработчик приложения может выбрать, устанавливать ли и когда обновленную версию пакета.

Есть и другие незначительные преимущества, которые я не буду использовать.в, но есть несколько очень веских причин, почему почти все основные языки программирования теперь предоставляют аналогичные функциональные возможности «пакет» и «канал» в качестве способа управления зависимостью от внешних проектов и библиотек.Я считаю, что ваш подход устарел и наивен, что приводит к проблеме, которую вы описали, а также к возникновению других раздражителей.