Может ли NuGet использовать пути загрузки пакетов для одного проекта?

Question

Рассмотрит репо/файловую структуру для нашего решения ...

Shared Repo (Checked out to D:/Shared/trunk) 
    ├───Shared1.dll Project 
    └───Shared2.dll Project 

App1 Repo (Checked out to C:/Code/App1/Trunk) 
    ├───App1 Project (Refs Shared1.dll project) 
    ├───App1.dll Project (Refs Shared1.dll and Shared2.dll projects) 
    └───App1.sln 

App2 Repo (Checked out to C:/Code/App2/Trunk) 
    ├───App2 Project (Refs Shared1.dll project) 
    ├───App2a.dll Project (Refs Shared1.dll and Shared2.dll projects) 
    ├───App2b.dll Project (Refs Shared1.dll and App2a.dll projects) 
    └───App2.sln 

Чтобы сделать работу с кодом проще, мы привносим в совместных проектах непосредственно в решение приложения, то есть, например, если вы откроете App1.sln , это будет ваше дерево проекта ...

App1.sln 
    ├───Shared1.dll Project 
    ├───Shared2.dll Project 
    ├───App1 Project (Refs Shared1.dll project) 
    └───App1.dll Project (Refs Shared1.dll and Shared2.dll projects) 

Как вы можете видеть, два общих библиотек DLL находятся в отдельном хранилище, но включены в это решение. Visual Studio обрабатывает это без каких-либо проблем, предлагая вам обновлять несколько репозиториев при выполнении коммита против решения. Все в порядке, и это именно то, что мы хотим.

Проблема, которую мы имеем, однако, связана с NuGet. Из того, что мы понимаем, NuGet.config (и иерархия/приоритет чтения/применения) относится к файлу решения, поэтому ссылки на проекты NuGet соответствующим образом обновляются. Это вызывает проблемы в том, что ссылки на пакеты NuGet в Shared1.dll Shared2.dll относительно App1.sln, когда вы работаете в App1.sln, то есть если кто-то еще работает в App2.sln и не проверял их два ствола относительно друг друга точно так же, как и у вас, перерыв ссылок.

Наша задача - всегда следить за всеми тремя соединительными линиями в той же папке, что и братья и сестры, затем поместить папку для упаковки в качестве другого брата, добавив «../packages» в NuGet.config рядом с каждым решением , Это гарантирует, что ссылки никогда не сломаются, но заставляет местоположение проверок, которые могут быть проблемой.

C:/Code/ 
    ├───Shared Trunk 
    ├───App1 Trunk 
    ├───App2 Trunk 
    └───packages 

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

C:/Code/ 
    ├───Shared Trunk 
    │ └─sharedpackages 
    ├───App1 Trunk 
    │ └─app1packages 
    └───App2 Trunk 
     └─app2packages 

Опять-таки, что мы хотим при открытии App1.sln, мы хотим, чтобы пакеты для Shared1.dll и Shared2.dll идти в папку, но пакеты «» sharedpackages используемых App1 и App1.dll идти в app1packages ,

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

Answer 1

Я в той же ситуации, что и/u/MarquelV.

Из моего исследования, посвященного вариантам, предоставленным nuget (по крайней мере, до версии 3.5) для решения такого рода сценариев, я пришел к выводу, что нужно полностью игнорировать графические инструменты для nuget внутри Visual Studio (по крайней мере, как что касается установки/восстановления пакетов), а также отключить автоматическое восстановление пакета (Tools -> Options -> Nuget и т. д.). Затем прибегаем к вызову nuget.exe из командной строки всякий раз, когда возникает необходимость установки/восстановления пакетов с указанием папки, в которой должны быть размещены пакеты, эта точка важна, потому что графические интерфейсы для nuget в visual studio изгибаются при хранении пакетов в «глобальный» репозиторий (обычно рядом с файлом .sln решения).

В моих проектах я создаю папку .nunit вместе с nuget.exe внутри каждого проекта и ссылочных dll.

Последнее, но не менее важно, чтобы каждый проект восстанавливал пакеты с помощью nuget через.csproj так:

<Target Name="BeforeBuild"> 
     <Exec Command=".\.nuget\nuget.exe restore .\packages.config -PackagesDirectory .\packages"/> 
</Target> 

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