2013-09-26 4 views
0

У меня есть assembly_A, что зависит от * some_framework * v2.1 от NuGet. Тогда у меня есть некоторые assembly_B, которая зависит от assembly_A, но когда я компилирую решение, это версия 2.0 - не 2.1 * some_framework *, который принес с assembly_B.Неверный вариант сборки с зависимостью

Мое предположение, что сборка выбрала v2.0, потому что это версия в моем GAC, но мне нужно v2.1 ... Никакая другая зависимость не использует * some_framework *. Очевидным обходом было бы сделать assembly_B зависит от * some_framework * v2.1 через NuGet, но это не очень элегантно!

Любые мысли?

Thanks

ответ

0

У вас есть уникальное решение? Если нет, попробуйте использовать nuget config file для хранения той же папки пакетов для ваших проектов.

Моя идея происходит это:

  • Вы установили depedency на assembly_A
  • На assembly_B (уже ссылка на assembly_A), вы используете код зависимости установлен (добавление dll на csproj)
  • На assembly_A, вы обновили свою зависимость от nuget, но на assembly_B (csproj), ссылка продолжает старую версию

Посмотрите на web.config> среда> assemblyBinding раздела версии выставиться вашим зависимости

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

+0

Спасибо за ваши мысли. На самом деле я считаю, что моя сборка B первоначально зависела от v2.0 от GAC (это роль рабочего Azure с начальной зависимостью от AzureStorage v2.0 при создании проекта), и моя сборка A имеет зависимость Nuget от AzureStorage v2.1. Я проверил все, но я продолжаю получать AzureStorage v2.0 при компиляции роли рабочего ... – ThomasWeiss

+0

Попробуйте «включить восстановление пакета» в своем решении. Возможно, на сборке/публикации исправлена ​​проблема. –

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