Можно ли сказать NuGet, где хранить пакеты для решения?

Question

Мне не удалось найти ответ на этот вопрос.Я использовал Nu ранее и имел возможность определить, где должны быть установлены «драгоценные камни».Например, мне нравится сохранять структуру моего проекта следующим образом:

MyProject
    |-MyProject.build
    |-MyProject.sln
    |-doc
    |-lib
    |  |- <i>... my packages/gems ...</i>
    |-sql
    |-src
    |  |-app
    |  |-test
    |-tools

Как вы можете видеть, мне нравится сохранять папку "lib" для сторонних библиотек, используемых в моем решении.Используя Nu, находясь в корневом каталоге моего проекта, я мог бы просто использовать команду:

nu install log4net <i>--location=lib</i>

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

Итак, возможно ли это с помощью «консоли диспетчера пакетов» в VS.NET?Должен ли я использовать какой-то другой метод?Спасибо за вашу помощь!

Answer 1

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

И это не должно предполагать решение == полное дерево исходных текстов . Для пояснения: мое дерево исходных текстов содержит более 80 решений, расположенных в разных местах, при репозитории пакетов относительно папки решений получается более 80 клонов всех пакетов, это медленно и расточительно.

на данный момент (nuget 1.3) недокументированный хак - поместить файл nuget.config рядом с вашим решением, указав в нем относительный путь к репозиторию, например

<settings>
    <repositoryPath>..\..\lib</repositoryPath>
</settings>

это может или не может работать для вас, поскольку это взлом.

Answer 2

Себастьен Ламбла написал недавнее сообщение в блоге , касающееся OpenWrap, но также и о NuGet. В нем он полагает, что люди, просящие разместить пакеты в других местах, действительно задают неправильные вопросы:

Когда вопрос «могу ли я изменить, куда идут пакеты», обычно основной, реальный вопрос, один из двух: «Я хочу, чтобы они были в / lib с остальными моими традиционными библиотеками» или «В моей корпоративной среде я не хочу регистрировать все зависимости, потому что меня не волнует развертывание xcopy ».

А затем продолжаем объяснять, что библиотеки, "принадлежащие" вашему менеджеру пакетов, на самом деле не такие звери, как другие библиотеки, от которых вы зависите.