Как установить динамический путь к ссылкам Nuget? - PullRequest
Новая
       14

Как установить динамический путь к ссылкам Nuget?

0 голосов
/ 26 апреля 2018

Вот пример структуры проекта: 

{ ProjectA }
    { packages } <-- packages are created here
    { ProjectA }
        - ProjectA.csproj <-- references ProjectB and C.
        - packages.config
    - ProjectA.sln <-- contains all projects: A, B and C.

{ ProjectB }
    - ProjectB.csproj
    - packages.config

{ ProjectC }
    - ProjectC.csproj
    - packages.config   

*{ packages} <-- *When I manually paste packages here. So one level above ProjectB.csproj file, then ProjectB compiles.

Решение ProjectA имеет все три проекта: A, B и C. ProjectA - ссылка ProjectB и ProjectC.

Когда я компилирую ProjectA (проекты B и C также компилируются), все пакеты nuget загружаются в папку {packages} на том же уровне, что и файл решения. Проблема в том, что ProjectB не компилируется. Да ... только ProejctB. Я даже не собираюсь исследовать, почему компилируется только один проект, хотя их конфигурация точно такая же. Так или иначе ...

Как в ProjectB, так и в C, когда я раскрываю References, dll из nuget видны как отсутствующие (с желтым прямоугольником). Так или иначе, ProjectC компилируется, а ProjectB - нет. В ошибках говорится, что не может найти ссылку, которая явно находится в папке с пакетами.

У меня вопрос, как мне запрограммировать / настроить эту отправку (код psuedo):

"Уважаемый ProejctB! Пожалуйста, найдите ссылки в папке пакета, созданные на том же уровне, что и файл решения. Файл решения, который пытается скомпилировать вас прямо сейчас. Спасибо"

PS. Технически, путь к dll (ссылка) будет довольно динамичным. Это изменится в зависимости от того, какой файл решения открывает / компилирует проект. Возможно ли это?

Ответы [ 3 ]

0 голосов
/ 27 апреля 2018

Поскольку packages.config постепенно устаревает, вы можете перенести свои проекты из packages.config в ProjectReference, где пакеты NuGet указаны в файле csproj, а для хранения пакетов используется общее глобальное расположение (и там нет ссылок на HintPath, которые нужно было бы изменить).

В VS 2017 версии 15.7 в контекстном меню узла ссылок (уже доступно в предварительном просмотре) будет возможность миграции:

migrate option

PackageReference уже поддерживается в VS 2017, начиная с 15.1 или 15.2, в предварительном просмотре только инструмент миграции.

Для новых проектов VS 2017 (текущая версия!) Вы уже можете выбрать эталонный стиль пакета по умолчанию и разрешить его выбор для новых проектов:

package reference style selection

0 голосов
/ 27 апреля 2018

Nuget 3.x имеет концепцию packages.config, и в этом имени имя и версия пакета указаны на 2 месте (в файле package.config и в файле .csproj)

Ссылка в конфигурации пакета должна быть такой: 

<package id="NewtonsoftJson" version="9.0.1" targetFramework="net46" />

Путь подсказки в csproj должен быть таким: 

<HintPath>..\packages\NewtonsoftJson.9.0.1\lib\net45\Newtonsoft.Json.dll</HintPath>

Здесь ".. \ packages" говорит, что поднимитесь на один уровень вверх (значит, на уровне решения) и найдите папку "packages".

Вы должны убедиться, что путь подсказки существует или нет. Версия пакета должна быть одинаковой (9.0.1) в обоих файлах (package.config и .csproj)

После успешной компиляции Porject C возникает проблема в пакетах, которые используются только ProjectB.

Если вы все еще сталкиваетесь с проблемой, пожалуйста, предоставьте ниже детали для дальнейшего анализа.

  1. "Конфигурация пакета"
  2. "ProjectB.csproj"
  3. msbuild log, чтобы узнать, в каком пакете вы сталкиваются с проблемой.
0 голосов
/ 26 апреля 2018

Самый простой способ исправить это, установив HintPath в: 

<HintPath>$(SolutionDir)\packages\...

в .csproj файлах ProjectB и ProjectC. Это буквально означает: "искать ссылки в папке пакета, сгенерированном на том же уровне, что и файл решения. Файл решения, который пытается скомпилировать вас прямо сейчас" *

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

...