Nu-Get & issue с зависимостями уровня проекта для проектов, на которые ссылаются многочисленные решения

Я пытаюсь выяснить, как лучше всего справиться с этим сценарием.

Скажем, у меня есть библиотека, на которую ссылаются несколько разных несвязанных решений, позвольте ей обратиться к WebServiceInterface.dll. Эта библиотека имеет зависимость от JSON.NET.

До NuGet

Двоичный JSON.NET ссылался через внешний SVN в проекте WebServiceInterface. Другие решения, которые зависели от WebServiceInterface, ссылались на проект (также как внешний SVN) и в результате вытащили как проект, так и его зависимости.

С NuGet

Я не понял, как заставить ссылку JSON.NET хранить в проекте WebServiceInterface (в отличие от местоположения пакетов RandomSolution \). Я нашел ссылку @nu-get для pacakges уровня проекта и уровня решения, но я не могу понять, как это указать, когда я добавляю зависимость через nu-get.

Целью здесь является то, что когда кто-то проверяет WebServiceInterface и добавляет его к новому решению, которое он создает (вместо того, чтобы сломать ссылки на JSON.NET, которые указывают на каталог пакетов под любым последним решением, которое было проверено).

Ответ 1

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

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

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

Ответ 2

Когда я пошел, чтобы узнать, создал ли Chris B проблему NuGet, я не смог ее найти. EDIT: Он сделал, см. Его комментарий ниже. Но я нашел полудокументированную функцию NuGet, которую я использовал для решения этой проблемы: Разрешить указывать папку, в которой установлены пакеты

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

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

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

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

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

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

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

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

Проблема 2:

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

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

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

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

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

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