Ссылочные сборки автоматически заменяются Visual Studio
У меня есть 2 проекта, портативная библиотека классов и обычный проект модульного тестирования. В переносимой библиотеке классов я использую NuGet для ссылки на пакет переносимости Microsoft.BCL, который поставляется с 2 сборками (System.Threading.Tasks.dll а также System.Runtime.dll оба v1.5).
Тем не менее, когда я пытаюсь сослаться на эти же библиотеки в моем проекте модульного тестирования (как с NuGet, так и вручную просматривая каталог \packages\Microsoft.Bcl.1.0.19\lib\portable-net40+sl4+win8+wp71), visual studio автоматически указывает ссылку на dll в другой папке, расположенной здесь C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\, которая имеет версию 4.5.
Теперь метод, который мне нужно проверить, принимает CancellationToken в качестве параметра и выдает ошибку компиляции: The type 'System.Threading.CancellationToken' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Threading.Tasks, Version=1.5.11.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' потому что его библиотека v4.5 является то, на что ссылаются, а не v1.5.
Однако я смог написать тесты для методов, которые не используют ни одну из этих функций из библиотеки BCL v1.5.
Почему Visual Studio заменяет мою библиотеку, на которую ссылаются, той, которая была в комплекте с фреймворком? Как мне сказать Visual Studio использовать только те, на которые я указываю, в определенном каталоге?
Использование Visual Studio 2012 Обновление 2.
3 ответа
Это казалось проблемой с обновлением Visual Studio 2, так как это не происходит с Visual Studio 2013. Я открыл проект в более новой версии Visual Studio, и были загружены правильные сборки.
Я не уверен, что плагин был причиной этого.
Ожидается, что ссылки на System.Runtime.dll v1.5/v2.5 и System.Threading.Tasks.dll v1.5/v2.5 будут заменены ссылками в платформе для проектов.NET Framework 4.5. Однако это должно происходить за кулисами и не должно быть заметным.
Я подозреваю, что произошло то, что вы начали с тестового проекта.NET Framework 4.0 и перенаправили его на.NET Framework 4.5. К сожалению, когда это происходит, NuGet не переустанавливает пакет, чтобы получить проект 4.5 в правильном состоянии. Чтобы попытаться это исправить, попробуйте следующее:
1) Удалите пакет Microsoft.Bcl.Async, включающий все его зависимости от всех проектов. Это можно сделать, щелкнув правой кнопкой мыши на обозревателе решений -> Управляемые пакеты NuGet для решения.
2) Откройте любой файл App.Config в каждом проекте, в котором установлен пакет, и удалите все записи assemblyBinding, которые ссылаются на System.Runtime и System.Threading.Tasks.
3) Убедитесь, что ни один проект не ссылается на System.Runtime и System.Threading.Tasks, если они есть, удалите ссылки
4) Переустановите пакеты
Это должно привести вас в хорошее состояние.
Обратите внимание, что это поведение улучшается в NuGet 2.7, где теперь выдается сообщение об ошибке / предупреждении о ретаргетинге, когда вы входите в это состояние.
Была похожая проблема (и могла бы спасти кого-то от разочарованного рабочего дня) - оказалось, что в справочном тракте в решении (щелкните правой кнопкой мыши ПРОЕКТ (не решение) и выберите свойства. В левой части находятся настройки для проекта (Приложение, Компиляция, отладка, ссылки и т. Д.).
Выберите "ссылки", а затем кнопку "Ссылки пути" над сеткой "Ссылки". Если какой-либо из приведенных здесь ссылок указывает на каталоги, в которых можно найти старые DLL, VS (в моем случае 2013) выберет здесь DLL.
Какой путь фактически используется для разрешения DLL, можно увидеть в сетке "ссылок".
Удалите все пути обсолте и перекомпилируйте.
Это также удалило NuGets "Не удалось сгенерировать перенаправления привязки для" XXYYZZ ". Элемент с тем же ключом уже добавлен".
Думал, что добавлю это, если это кому-то поможет.
У меня была сторонняя DLL (версия 3.0.120) в папке Dependencies, и я ссылался на нее в проекте, и все работало нормально.
Новая версия DLL была выпущена через NuGet. Он был установлен в:
.. \ пакеты \Independencentsoft.Exchange.3.0.530\Lib\net45\
Чтобы использовать новую DLL, я удалил старую ссылку, очистил проект и добавил новую DLL в качестве новой ссылки.
Затем я скомпилировал и развернул (я работаю с SharePoint) проект, но код не удался, и отладка показала, что он все еще использует старую ссылку, хотя я ее удалил.
Затем я заметил, что при изучении свойств новой ссылки в VS номер версии DLL всегда был старым (3.0.120), а не новым (3.0.530).
Спустя много часов я удалил старую DLL в папке Dependencies, очистил, построил и развернул проект, и все заработало нормально.
Похоже, что до тех пор, пока в проекте присутствовала старая DLL, VS продолжал указывать любые новые ссылки на новую версию обратно на старую версию.
Надеюсь, это кому-то поможет.