2016-11-15 3 views
0

У меня есть пакет X в зависимости от другого пакета Y. По умолчанию (Visual Studio 2015 Upd3 + nuget 3.5) любой проект, ссылающийся на пакет X, будет обновляться со ссылкой на пакет Y тоже. Проблема в том, что клиентам X вообще не нужна ссылка на Y, поскольку API пакета Y не является и не должен подвергаться воздействию клиентов.Нетранзитивные зависимости пакетов?

Итак, ожидаемое поведение следующее: после добавления ссылки на пакет X содержимое пакета Y должно быть скопировано в папку вывода при сборке, но пакет Y не должен быть добавлен в ссылки на проект.

Есть ли какой-либо способ?

Теоретически мы можем включить источники пакета инфраструктуры Y в наш проект X (оба проекта являются openource под лицензией MIT), но я предпочел бы использовать более или менее стандартный подход.

Пример случаев, почему нам нужно это:

  • Случая мы расследуем прямо сейчас: NuGet пакет с тестом-помощником, который гарантирует, что PDB файлы соответствуют источникам (справки Microsoft.DiaSymReader пакета). Мы не хотим, чтобы все наши тестовые проекты ссылались на сборку Microsoft.DiaSymReader.

  • Более или менее теоретический (не проблема на данный момент, но будет проблемой, если проект будет запущен в производство): механизм пользовательского сценария, который использует Roslyn для компиляции и запуска скриптов. Мы не хотим ссылаться на сборки Roslyn во всех проектах, которые будут использовать наш скриптовый движок.

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

Любые предложения приветствуются!

ответ

0

Поскольку вы являетесь автором пакета X, это зависит от вас, что вы включаете в свой файл nupkg. Вы также можете включить сторонние DLL.

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

+0

Да, мы также рассматриваем этот вариант, но это может привести к неразрешимому конфликту зависимости. В качестве примера: мы поставляем Y.dll v1.0 как часть нашего пакета X, сторонний проект ссылается на наш пакет X, а затем добавляет явную ссылку на пакет Y v2.0. Это определенно не подходит для крупных инфраструктурных зависимостей, таких как Roslyn. Поэтому мы предпочли бы остаться с нормальными зависимостями nuget, но не включив их в ссылки на проекты клиентов. – Sinix

0

Вы можете добавить DLL пакета Y в качестве файлов содержимого в Пакет X, который не добавит Y dll в проект, который установил пакет X.

Следующие шаги показывают, как создать пакет X с Y dll в качестве файлов содержимого.

  1. Добавить Y dlls в проект пакета X, добавив -> Существующие элементы.
  2. Выделить все Y dll и щелкнуть правой кнопкой мыши, чтобы открыть окно «Свойства», установите «Копировать в выходной каталог» как «Копировать всегда».
  3. Пакет Project X в качестве пакета X с nuget.exe

Теперь, когда вы открываете пакет X.nupkg файл с NuGet Package Explorer, вы найдете DLLs Y, хранящиеся в папке содержимого. И когда вы устанавливаете пакет X в другом проекте, Y-файлы DL будут добавлены в проект в качестве файла содержимого. После сборки проекта, DLL-файлы Y будут скопированы в выходной каталог.

+0

Это то же самое, что и @ botond.botos. Это приведет к проблемам с версиями, если наши клиенты добавят прямую ссылку на пакет Y. – Sinix

+0

Если ваши клиенты добавляют прямую ссылку на Y-библиотеки, которые имеют разные версии с вашим X-пакетом, они могут перенаправлять версии сборки в файл конфигурации приложения: https://msdn.microsoft.com/en-us/library/7wd6ex19(v= vs.110) .aspx # Anchor_2 –

+0

Да, но функция консолидации nuget не будет работать для таких конфликтов, их пришлось разрешить вручную. Не вариант, если пакет Y огромен, roslyn в качестве примера. – Sinix

Смежные вопросы