Есть ли способ, чтобы несколько приложений ссылались на глобальный проект, который имеет другие ссылки на проекты?
После долгих поисков я, похоже, не смог найти ответ на свою проблему. Обычно я считаю, что это означает, что это несуществующий или неправильный подход, но, тем не менее, я думаю, что ответ на него стоит того, чтобы найти ответ в Интернете.
По сути, у нас есть 4 приложения, ссылающиеся на 5 разных «исходных» проектов. Таким образом, сценарий таков: когда мы добавляем 5-е приложение (например), нам нужно будет создать ссылки на другие 5 разных проектов, поскольку приложению требуются их выходные данные.
Это несложная задача, потому что количество проектов невелико, но она заставила нас задуматься. Что, если бы вы могли создать один проект, который может называться Libs или что-то в этом роде, ссылаться на все 5 проектов в этом проекте, а затем приложения должны ссылаться только на Libs. Идея кажется крутой, но я не знаю, сработает ли она, потому что когда вы создаете ссылку на проект, она указывает на Libs single output libs.dll.
Так что на самом деле задать вопрос, возможно ли это, и если да, то как это можно сделать? В настоящее время, когда Libs ссылается на другие «исходные» проекты, а затем приложения ссылаются на проект Lib, это не работает, поскольку в нем говорится, что отсутствуют сборки.
И просто рассказать, как это было создано. 5 исходных проектов находятся в нескольких разных решениях, поэтому единственная утомительная часть этого подхода — «добавить существующий проект» при начальном запуске решения приложения.
Ответы 1
Способ, которым мы управляем такого рода вещами в моей организации, заключается в создании пакета NuGet для каждого из этих общих «исходных» проектов (например, в нашем случае у нас есть библиотека регистрации ошибок, библиотека утилит XML, специальный HTTP-клиент и другие). ). Они публикуются по нашему частному URL-адресу фида NuGet (размещенному на Azure DevOps, но при необходимости вы можете просто использовать стандартную общую папку Windows) для использования нашими разработчиками в своих приложениях.
Это имеет некоторые явные преимущества перед вашим подходом:
1) Зависимости - это кажется наиболее актуальным для вашего вопроса. Если проект, из которого вы создали пакет NuGet, зависит от каких-либо других пакетов NuGet (либо общедоступных, либо других из нашего частного канала), тогда, когда кто-то устанавливает этот пакет в своем проекте, он автоматически устанавливает все остальные пакеты, от которых он зависит.
Таким образом, в вашем случае вы можете создать пакет оболочки «libs», который сам не доставляет никакого контента, но имеет зависимости от всех ваших других пакетов, что приводит к их автоматической установке. В нашем случае у нас есть несколько случаев зависимости (например, «базовый» пакет регистрации ошибок, на который опираются модули обработки ошибок, адаптированные для различных типов приложений, например MVC, веб-API, службы Windows), и он работает очень хорошо.
2) Обновления и обслуживание. В вашем сценарии, если вы вносите критические изменения в один из ваших «исходных» проектов, то, поскольку у вас есть прямая ссылка на проект, объявленная в Visual Studio, любой проект, который ссылается на исходный, должен будет внести соответствующие изменения, чтобы справиться с обновлениями в исходный проект, прежде чем вы сможете перекомпилировать его и внести любые изменения функций, которые вы пытаетесь достичь. Это может быть проблемой и несвоевременной проблемой, особенно в случае крупных обновлений. Однако, если вместо этого вы устанавливаете пакет NuGet, содержащий эту функциональность, разработчик приложения может выбрать, следует ли и когда устанавливать обновленную версию пакета.
Есть и другие незначительные преимущества, о которых я не буду говорить, но есть несколько очень веских причин, по которым почти все основные языки программирования теперь предоставляют аналогичные функции «пакетов» и «каналов» как способ управления зависимостью от внешних проектов и библиотек. . Ваш подход, как мне кажется, устарел и наивен, что приводит к описанной вами проблеме, а также к другим раздражениям.
Microsoft (и другие) имеют множество документации, руководств и т. д. о создании пакетов NuGet, они существуют уже много лет, вы можете легко найти их в Google. Это, вероятно, хорошее место для начала: docs.microsoft.com/en-us/nuget/create-packages/… . P.S. Если вы создаете библиотеки для .NET Standard или .NET Core (а не для .NET Framework), теперь в Visual Studio встроены инструменты с графическим интерфейсом, которые упрощают этот процесс. В этой статье: docs.microsoft.com/en-us/nuget/хостинг-пакеты/обзор рассказывается о вариантах размещения фидов NuGet.
Прекрасный! Любая документация по настройке. Ссылки, которые работали для вас?