Проблемы со ссылками на TPL Data Flow и TPL в VS 2012 RC

Я только что обновил бета-версию Visual Studio 11 до новой версии Visual Studio 2012 RC и столкнулся с проблемами, связанными с потоком данных TPL.

Во-первых, я попытался ссылаться на Dataflow, как и раньше, добавив ссылку из фреймворка. Но когда я пытаюсь это сделать, у меня появляется окно с ошибкой:

Ссылка на "System.Threading.Tasks.Dataflow" не может быть добавлена.

а затем вся Visual Studio замерзает.

После чтения пакетов NuGet потока MEF и TPL для .NET Framework 4.5 RC я предположил, что версия Dataflow, показанная в списке ссылок, была своего рода артефактом предыдущая установка. Итак, я попытался использовать Dataflow из NuGet, который, казалось, работал, пока я не попытался скомпилировать мой код, потому что у меня возникла ошибка:

Тип "System.Threading.Tasks.Task" определен в сборке, на которую не ссылаются. Вы должны добавить ссылку на сборку "System.Threading.Tasks, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a".

Это сбивает с толку, потому что Task находится в mscorlib, никакие другие ссылки не нужны. Но в списке ссылок есть ссылочная сборка под названием System.Threading.Tasks, поэтому я попытался добавить это. К сожалению, знакомая ошибка показала:

Ссылка на "System.Threading.Tasks" не может быть добавлена.

а затем Visual Studio снова замерзает.

Я что-то делаю неправильно? Как я могу использовать поток данных TPL с VS 2012 RC?

Ответ 1

Попробуйте "Добавить ссылку" System.Threading.Tasks.dll явно из C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETCore\v4.5. В качестве альтернативы вы можете использовать каталог C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\Facades.

ОБНОВЛЕНО. Я рассмотрел проблему больше после прочтения ответа об удалении ссылки на System.Runtime, и я могу добавить следующее: Ссылка на System.Runtime будет добавлена из-за ошибки в currect версии пакета NuGet Microsoft.Tpl.Dataflow.4.5.1-rc. Если добавить ссылку на тот же System.Threading.Tasks.Dataflow.dll непосредственно в Visual Studio, то ссылка no System.Runtime будет добавлена, и проблем не будет.

Используя NuGet Package Explorer, вы можете загрузить оригинал Microsoft.Tpl.Dataflow.4.5.1-rc.nupkg из официального источника пакета NuGet. В конце пакета Matadata вы увидите

Можно изменить метаданные (нажмите Ctrl-K) и удалите ссылку:

После этого можно сохранить измененный файл Microsoft.Tpl.Dataflow.4.5.1-rc.nupkg в некотором каталоге. После добавления нового местоположения (локального каталога) в список источников NuGet (см. здесь или здесь) можно будет добавить новый пакет из локального источника (не забудьте выбрать отображение всех пакетов, включая предварительный выпуск, см. рисунок ниже):

Измененный Microsoft.Tpl.Dataflow.4.5.1-rc.nupkg не добавит System.Runtime, и проект будет скомпилирован без ошибок.

Таким образом, ошибка существует не в Visual Studio 2012 RC и даже не в Microsoft.Tpl.Dataflow.dll. Ошибка находится только в метаданных предварительной версии пакета Microsoft.Tpl.Dataflow NuGet, доступного в настоящее время на официальном источнике пакета NuGet.

Вы можете опубликовать отчет об ошибке в автора, чтобы пакет был исправлен.

ОБНОВЛЕНО 2. Даже если мой ответ уже отмечен как решенный, и награда, присуждаемая этой проблемой, все еще не уходит с моей головы. На самом деле я вижу две открытые проблемы:

Почему существование неиспользуемой сборки System.Runtime может привести к ошибке во время создания проекта.
Я вижу некоторые общие проблемы в том, как работает удаление или обновление пакетов NuGet (подробнее см. подробнее).

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

Создайте новое пустое консольное приложение в Visual Studio 2012 RC.
Убедитесь, что проект не имеет ссылки на System.Runtime.
Откройте "Консоль диспетчера пакетов" в "Инструменты" / "Менеджер пакетов библиотек".
Выполните команду "Install-Package Microsoft.Tpl.Dataflow -Pre" в "Консоль диспетчера пакетов" .
Убедитесь, что как System.Runtime, так и System.Threading.Tasks.Dataflow включены в список ссылок проекта.
Выполните команду "Удалить пакет Microsoft.Tpl.Dataflow" в "Консоль диспетчера пакетов" .
Убедитесь, что System.Threading.Tasks.Dataflow удалены из списка ссылок проекта, , но System.Runtime все еще находится в списке ссылок.

Я сделал еще один эксперимент, и я изменил версию модифицированного Microsoft.Tpl.Dataflow.4.5.1-rc.nupkg, где я удалил ссылку на System.Runtime, от 4.5.1-rc до 4.5.1-rc1 и сохранил ее локально (она будет сохранена в Microsoft.Tpl.Dataflow.4.5.1-rc1.nupkg). После этого я мог увидеть "новую" версию в списке обновлений для моего проекта:

Если я установлю обновление, ссылка на System.Runtime также не будет удалена.

Таким образом, текущая реализация "Обновление" и "Удаление" NuGet имеет проблему с ошибкой или общим дизайном. Если мы добавим пакет в наш проект и внесем некоторые обновления проекта, мы получим ссылки на все зависимые сборки всех старых версий. Старые ссылки, добавленные NuGet из старых версий пакета, не будут удалены во время удаления или обновления. Прежде всего, нехорошо иметь мусор в ссылках на проект, но из-за существования существует первая проблема (ошибка при компиляции, если ссылка на unreferenced System.Runtime), проблема будет еще более серьезной.

Итак, если в NuGet ничего не изменится, обновление до следующей версии Microsoft.Tpl.Dataflow не решит проблему для пользователей, которые установили Microsoft.Tpl.Dataflow в версии 4.5.1 (или, возможно, на ранней версии). Все пользователи должны будут удалить ссылку на System.Runtime вручную. Я думаю, что это настоящая проблема NuGet, которая должна быть решена разработчиками NuGet. Я опубликую описание проблемы http://nuget.org/позже.

Отчет об ошибке, который я отправил в NuGet, можно найти здесь (извините за неточное форматирование текста).

Ответ 2

Согласно Алоку Шрирам из MS, решение состоит в том, чтобы удалить ссылку на System.Runtime и что это будет исправлено в следующем выпуск.

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