System. * Проблемы с ссылкой при введении зависимости NETStandard.Library

В большом решении с 52 проектами (все net462) последняя версия некоторых наших зависимостей теперь построена только для стандарта NET. Поэтому они зависят от пакета NuGet NETStandard.Library который, в свою очередь, перетаскивает многие другие версии 4.3.x пакетов System.* Которые обычно находятся в самой.NET Framework.

В результате некоторые проекты ссылаются на System.* Библиотеки из папки пакетов, в то время как другие ссылаются на System.* Библиотеки из.NET Framework.

Это приводит к известной проблеме времени выполнения, fe:

Сообщение: System.IO.FileLoadException: Не удалось загрузить файл или сборку "System.Net.Http, Version = 4.1.1.2, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a" или одна из его зависимостей. Расположенное определение манифеста сборки не соответствует ссылке на сборку. (Исключение из HRESULT: 0x80131040)

Копаясь в зависимостях пакетов NETStandard.Library, мы видим, что та же проблема существует и в этих пакетах:

System.Collections. *
System.ComponentModel. *
System.Console
System.Globalization. *
System.IO. *
System.Linq. *
System.Net. *
System.ObjectModel
System.Reflection. *
System.Resources.ResourceManager
System.Runtime. *
System.Text. *
System.Threading. *
System.Xml. *

Обычно это фиксируется установкой того же пакета в других проектах, но мы имеем дело с большим количеством проектов и множеством пакетов здесь, и я не хочу слепо добавлять все эти зависимости во все 52 проекта.

Это заставило меня задаться вопросом, знает ли кто-нибудь о том, как легко восстановить эту ситуацию, и чтобы все проекты ссылались на правильный пакет /DLL из папки пакетов NuGet, если они в настоящее время используют внутреннюю среду NET Framework.

Простое VS-решение для net462 и net471, демонстрирующее проблему, можно найти здесь

Ответ 1

В шаблоне проекта по умолчанию System.Net.Http добавляется в проект как ссылка, а не как пакет nuget.

В обоих ваших решениях (4.6.1 и 4.7.1):

Project ClassLibrary имеет зависимость от System.Net.Http как пакета nuget.
Project ConsoleApp1 имеет зависимость от System.Net.Http как простую ссылку с.NET Framework

Таким образом, проблема не связана с версией Target Framework.

Чтобы устранить проблему, добавьте ту же версию System.Net.Http как пакет nuget во все проекты (где он используется).

Щелкните правой кнопкой мыши решение в обозревателе решений и выберите " Manage NuGet Packages for Solution...
Переключиться на вкладку " Installed "
Найдите в списке System.Net.Http, выберите его.
Проверить текущее состояние:

Установите ту же версию пакета (4.3.0 в вашем случае) в проект ConsoleApp1.
Проверьте результат:

Перестройте решение.

Готово.

Кроме того, хорошая практика заключается в том, чтобы версии пакета были объединены в вашем решении. Вместо этого у вас могут быть конфликты версий во время сборки. Или, что хуже, ошибка времени выполнения, например MethodNotFound из-за MethodNotFound связывания с другой версией зависимостей.

Причина проблемы с System.Net.Http описана здесь: Broken System.Net.Http 4.1.1-4.3.0 post-mortem в разделе Как предотвратить такую ситуацию в будущем? 2,1

В результате мы определили 2 проблемных пакета OOB, которые не являются листовыми узлами в самой платформе, и имеют зависимость от платформы на них - System.Net.Http и System.IO.Compression.

Это означает, что System.Net.Http та же библиотека System.Net.Http поставляется в.NET Framework и как пакет OOB (вне диапазона) nuget. И некоторые пакеты nuget могут ссылаться на версию nuget. И здесь возникает проблема, которую я описал в самом начале.

Таким образом, вам не нужно фиксировать ссылки на все библиотеки System.*. Только для этих двух: System.Net.Http и System.IO.Compression.