Ссылки на сборки автоматически заменяются Visual Studio

У меня есть 2 проекта, переносимая библиотека классов и обычный проект модульного тестирования. В библиотеке переносимых классов я использую NuGet для ссылки на пакет переносимости Microsoft.BCL, который поставляется с двумя сборками (System.Threading.Tasks.dll и System.Runtime.dll, обе версии 1.5).

Однако, когда я пытаюсь сослаться на эти же библиотеки DLL в моем проекте модульного тестирования (как с помощью 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 2012 с обновлением 2.


visual-studio .net portable-class-library
person Shawn Mclean    schedule 08.07.2013    source источник
comment
Код PCL для модульного тестирования имеет была проблема. Обходной путь - создать тесты для конкретных платформ, которые вы хотите поддерживать.   -  person Hans Passant    schedule 08.07.2013

Ответы (4)


arrow_upward
1
arrow_downward

Ожидается, что ссылки на 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, где теперь они будут выдавать ошибку / предупреждение при перенацеливании, когда вы переходите в это состояние.

person David Kean    schedule 10.07.2013
comment
Я только что сделал это и столкнулся с той же проблемой. Я создал тестовый проект .net 4.5 и сослался на эти точные библиотеки v1.5, Visual Studio все равно указала на C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\Facades\System.Runtime.dll и т. Д. - person Shawn Mclean; 11.07.2013
comment
Как вы ссылаетесь на двоичные файлы? Не напрямую ссылаться на эти двоичные файлы - позвольте NuGet установить пакет. Если проблема все еще возникает, вы можете использовать ссылку «Связаться с владельцами» на этой странице: nuget.org/ пакеты / Microsoft.Bcl / 1.0.19. И мы организуем репродукцию. - person David Kean; 11.07.2013

arrow_upward
1
arrow_downward

Это выглядело как проблема с обновлением Visual Studio 2, поскольку этого не происходит с Visual Studio 2013. Я открыл проект в более новой версии Visual Studio, и были загружены правильные сборки.

Я не уверен, что причиной этого был плагин.

person Shawn Mclean    schedule 15.09.2013

arrow_upward
0
arrow_downward

Была аналогичная проблема (и могла спасти кого-то от разочарованных дней работы) - оказалось, что Пути ссылок в решении (щелкните правой кнопкой мыши ПРОЕКТ (не решение) и выберите свойства. В левой части находятся настройки для проекта (Приложение, Компиляция, отладка, ссылки и т. Д.).

Выберите «ссылки», а затем кнопку «Пути ссылок» над сеткой «Ссылки». Если какой-либо из ссылок здесь указывает на каталоги, в которых можно найти СТАРЫЕ DLL, VS (в моем случае 2013) выберет DLL отсюда.

Какой путь фактически используется для разрешения DLL, можно увидеть в сетке «ссылок».

Удалите все устаревшие пути и перекомпилируйте.

Это также удалило NuGets «Не удалось создать перенаправления привязки для XXYYZZ. Элемент с таким же ключом уже был добавлен».

person Toke Breer-Mortensen    schedule 02.04.2014

arrow_upward
0
arrow_downward

Думал, что добавлю это, если это кому-то поможет.

У меня была сторонняя 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 продолжал указывать любые новые ссылки на новую версию обратно на старую версию.

Надеюсь, это кому-то поможет.

person Jimmy    schedule 06.09.2019