Nu-Get и проблема с зависимостями на уровне проекта для проектов, на которые ссылаются несколько решений

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

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

Я рекомендую опубликовать сообщение в системе отслеживания проблем NuGet, чтобы начать обсуждение. Люди, работающие над этим, кажутся довольно активными, поэтому они могут добавить поддержку в будущей версии :-)

Когда я пошел узнать, создал ли Крис Б. проблему NuGet для этого, я не смог ее найти. РЕДАКТИРОВАТЬ: Он сделал, смотрите его комментарий ниже. Но я нашел полудокументированную функцию NuGet, которую использовал для решения этой проблемы: Разрешить указывать папку, в которой находятся пакеты установлены

Позвольте мне разбить этот вопрос на 2 вопроса:

1. заставить NuGet разрешить нескольким решениям использовать одно и то же расположение пакетов
2. получение пакетов NuGet для автоматического извлечения из системы управления версиями при включении проекта с пакетами NuGet

Проблема 1. По умолчанию NuGet хранит пакеты в папке пакетов в папке решения. Чтобы изменить это расположение, создайте файл nuget.config в корневой папке решения со следующим содержимым:

<settings>
<repositoryPath>..\..\..\Utilities\Library\nuget.packages</repositoryPath>
</settings>

<repositoryPath> относится к вашему решению; так что, очевидно, делайте все, что хотите. Сделайте так, чтобы каждое решение имело собственный относительный путь к одной и той же папке пакетов.

Что касается потока NuGet, с этого момента пути в repositories.config относятся к папке, содержащей repositories.config, а не к решению, поэтому теперь все проекты/пакеты управляются независимо от местоположения решения.

Это позволяет нескольким решениям использовать одни и те же пакеты в системе управления версиями, и если эти решения используют одни и те же проекты (которые используют пакеты NuGet), все эти решения/проекты будут синхронизироваться независимо от того, какое решение обновляет пакет.

Проблема 1 полностью решена.

Проблема 2:

Позвольте мне рассмотреть это с двух точек зрения. Это относится к Visual Studio и TFS — я оставлю SVN для кого-то другого.

Во-первых: если у вас нет исходного кода на вашем диске и вы получаете решение (не проект), я предпочитаю сделать так, чтобы вы получили все, что нужно для сборки решения. Не должно быть отсутствующих ссылок для захвата вручную. Этого мы можем добиться, добавив файлы пакетов в качестве элементов решения. Да, в каждом решении. Немного работы, да, но когда это будет сделано, файлы пакета будут загружаться/обновляться из системы управления версиями автоматически.

Во-вторых: в новом решении, когда вы включаете существующий проект системы управления версиями, содержащий пакеты NuGet, вам необходимо вручную получать пакеты из системы управления версиями и добавлять их в качестве элементов решения. По крайней мере, любой, кто получит ваше решение в будущем, автоматически получит все необходимое для успешной сборки. По крайней мере, с VS/TFS это именно так, насколько я знаю. Если projB зависит от projA и вы добавляете projB в новое решение, VS/TFS не будет автоматически получать projA из TFS. Вы должны сделать это вручную. То же самое относится и к ссылкам на dll (например, к пакетам NuGet).

Резюме моего решения:

• Только одна копия пакетов в системе контроля версий для всех решений
• Любое решение может обновлять пакеты, и все остальные решения будут синхронизированы*

* Как только одно решение обновит пакеты до новых путей или имен файлов, они будут отображаться как отсутствующие ссылки на другие решения, и вам придется вручную очистить это. Но, по крайней мере, вы точно знаете, где находятся пакеты в системе управления версиями «(в отличие от местоположения RandomSolution\packages)».