Различные зависимости в зависимости от типа целевого проекта - PullRequest
Новая
       2

Различные зависимости в зависимости от типа целевого проекта

4 голосов
/ 30 декабря 2011

У меня есть пакет Ninject.Extensisons.Wcf, который должен быть установлен по-разному в зависимости от типа проекта, в который он установлен. В случае, когда WCF размещен в IIS (любой проект, содержащий global.asax), второй пакет Ninject.Web.Common должен быть установлен вместе с пакетом. Для всех других типов проектов, таких как библиотеки, приложения Console, WinForms, WPF, этот пакет устанавливать не следует.

Возможно ли как-то добиться этого, например, используя скрипт powershell? Или мне нужно развернуть два разных пакета в этом случае?

1 Ответ

4 голосов
/ 03 января 2012

К сожалению, текущий файл nuspec не обеспечивает управление зависимостями в зависимости от типа проекта.В настоящее время мы поддерживаем таргетинг на разные версии фреймворка, но это не применимо в вашей ситуации.

Рекомендуется обрабатывать все зависимости с использованием ссылок на пакеты.Хотя технически можно было бы загрузить и установить пакет с помощью сценария PowerShell, это не поддерживается и, скорее всего, сломается в будущих версиях.

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

Если окажется, что наличие веб-зависимости вызывает нежелательные побочные эффекты, то вам нужно будет создать отдельные пакеты.

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

Итак, теперь у вас есть 2 логических пакета:

  • MyProject
  • MyProject.Web
    • MyProject (зависимости)
    • SomeOtherPackage

Таким образом, пользователь будет Install-Package MyProject для не-веб-проектов и Install-Package MyProject.Web для веб-сайтовпроекты.

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

На этом этапе определите типичный вариант использования вашего пакета.Если 90% ваших пользователей будут устанавливать веб-версию, я бы сделал «мета-пакет», в котором просто есть зависимости для ваших общих пакетов.

В вашем случае я бы сделал 3 пакета:

  • MyProject ( метапакет )
    • MyProject.Web
  • MyProject.Web
    • MyProject.Core
    • SomeOtherPackage
  • MyProject.Core (обычный не-веб-пакет)

Путем создания «мета-пакета»Вы можете зарезервировать «короткое» имя пакета для наиболее распространенного случаяЭтот метапакет имеет зависимости только от других пакетов.

Хорошим примером этого является пакет SignalR.

Надеюсь, это было полезно.

...