Как бороться с пакетами x86 и x64

Мы используем NuGet для управления нашими сторонними пакетами.

Теперь мы имеем зависимость от пакета NuGet (zeromq), который зависит от C dll и поэтому имеет релизы x86 и x64.

При поиске в Nuget я вижу только два разных проекта (zeromq x64 и zeromq x86), а не один унифицированный проект.

Наш процесс сборки на машинах-разработчиках состоит в том, чтобы выбрать соответствующую конфигурацию (например, Debug/x86, Release x64 и т.д.) в визуальной студии и построить, чтобы любое используемое нами решение должно было вписаться в графический интерфейс визуальной студии (то есть, для MSBuild soltuions не будет "действительно соответствовать нашему текущему рабочему процессу".

Добавление к ограничению.... Если мы не сможем сделать это автоматически в NuGet, есть ли способ сделать это с помощью какой-либо предварительной сборки powershell script? т.е. если мы знаем, что мы строим сборку x86, есть ли способ подключить NuGet, чтобы он использовал пакеты x86 вместо пакетов x64?

Каков правильный способ управления пакетами NuGet, подобный этому?

Ответы

Ответ 1

Тогда у вас есть два подхода:

Создайте свою собственную вилку ZeroMQ и следуйте System.Data.SQLite.org, чтобы реализовать предварительную загрузку собственной библиотеки. Затем вы можете создать один пакет NuGet вместо двух.
Создайте два проекта для своего исполняемого файла (тот же исходный код, всего два файла проекта). Один для x86, а другой для x64. Добавьте пакет ZeroMQ x86 к вашему x86, а ZeroMQ x64 - к вашему x64. Это некрасиво, но IHMO избегает кондиционирования в вашем файле проекта (который можно легко сломать любым плохим парсером MSBuild).

Ответ 2

Я бы подумал, что хорошее место для просмотра будет http://docs.nuget.org/docs/reference/package-manager-console-powershell-reference

Насколько я понимаю, NuGet действительно просто Powershell для сборки. Я бы предложил настроить условную сборку на основе компиляции текущей платформы (86/64), а затем отфильтровать Get-Package до нужной вам версии.