У меня странная проблема, которая сводит меня с ума…
У меня есть простой проект библиотеки классов (Full .NET Framework, 4.6.1) с классом-оболочкой для функциональности Cosmos DB. Поэтому я добавил в этот проект пакет NuGet 1.19.1 «Microsoft.Azure.DocumentDB». Помимо этого, у меня есть ссылка на пакет NuGet «Newtonsoft.Json» 10.0.3, а также на несколько пакетов NuGet «Microsoft.Diagnostics.EventFlow. *».
Пока все компилируется без ошибок.
Но как только я попал в свой класс-оболочку, полученный из простой службы Service Fabric без сохранения состояния (Full .NET Framework 4.6.1), и попытался выполнить следующую строку кода:
_docClient = new DocumentClient(new Uri(cosmosDbEndpointUrl), cosmosDbAuthKey);
Я получаю эту странную ошибку во время выполнения:
System.IO.FileNotFoundException возникло HResult = 0x80070002
Сообщение = Не удалось загрузить файл или сборку System.Net.Http, Version = 4.2.0.0, Culture = нейтральный, PublicKeyToken = b03f5f7f11d50a3a или одну из его зависимостей. Система не может найти указанный файл.
Источник = StackTrace: в Microsoft.Azure.Documents.Client.DocumentClient.Initialize (Uri serviceEndpoint, ConnectionPolicy connectionPolicy, Nullable1 desiredConsistencyLevel) at Microsoft.Azure.Documents.Client.DocumentClient..ctor(Uri serviceEndpoint, String authKeyOrResourceToken, ConnectionPolicy connectionPolicy, Nullable
1 requiredConsistencyLevel)Внутреннее исключение 1: FileNotFoundException: не удалось загрузить файл или сборку System.Net.Http, Version = 4.0.0.0, Culture = нейтральный, PublicKeyToken = b03f5f7f11d50a3a или одну из его зависимостей. Система не может найти указанный файл.
Я совершенно не понимаю, почему сборка System.Net.Http вообще не найдена - в моем проекте библиотеки классов есть даже ссылка на сборку .Net Framework Assembly «System.Net.Http 4.0.0.0».
Я также не понимаю, что это странное перенаправление привязки на 4.2.0.0 - откуда оно? Чтобы обойти это, я попытался добавить следующее перенаправление в app.config службы Service Fabric (которая использует библиотеку классов):
Но все равно никакой разницы, я все равно получаю ошибку во время выполнения.
У кого-нибудь есть подсказка? Кто-нибудь видел такую проблему?
Спасибо и привет, OliverB
Ответы:
Проблема, с которой вы столкнулись, связана с Visual Studio, особенно с 2017, который поставляется вместе с ним
System.Net.Http v4.2.0.0
. Однако переход на новый способ, при котором любые ссылки должны выполняться через NuGet, последняя версияSystem.Net.Http
которого 4.3.3 содержит dll версии 4.1.1.2.Проблема в том, что VS во время сборки и во время выполнения будет игнорировать вашу ссылку и попытается ссылаться на DLL, о которой он знает.
Как это исправить:
c:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\
); если у вас другая версия, то путь будет немного отличаться, хотя и не сильноОшибки времени выполнения: добавьте перенаправление привязки сборки
Если вы посмотрите в Интернете в Google, вы найдете несколько открытых проблем с Microsoft по этому поводу, поэтому, надеюсь, они исправят это в будущем.
Надеюсь это поможет.
Обновить:
При поиске некоторых постоянных исправлений этой проблемы для работы с агентами сборки заметил, что при переходе на новую модель NuGet PackageReference (
.csproj
неpackages.config
входит) работает лучше. Вот ссылка на руководство по выполнению этого обновления: https://docs.microsoft.com/en-us/nuget/reference/migrate-packages-config-to-package-referenceисточник
Удаление перенаправления привязки сработало для меня, вы можете попробовать удалить его:
источник
dependentAssembly
Дополнение к ответу, который уже дал @AndreiU, и о том, как локально воспроизводить ошибки времени выполнения.
При развертывании в Azure, а не локально, я получил указанную ниже ошибку времени выполнения.
Когда я начал рассматривать сборки, я увидел, что мой веб-проект и проект службы ориентированы на разные версии для
System.Net.Http
.Веб-проект:
Сервисный проект:
Легко подумать, что это вызвано несоответствием версий, но главное здесь - посмотреть на ошибку
The system cannot find the file specified.
.Глядя на свойство path, мы видим, что веб-проект нацелен на сборку .Net Framework, а служба нацелена на сборку из Visual Studio 2017. Поскольку на сервере не установлена Visual Studio 2017, произойдет ошибка времени выполнения.
Веб-путь:
Путь обслуживания:
Что - то же просто , как установка ,
Copy Local
чтобыtrue
можно решить эту проблему, однако не во всех случаях.Чтобы воспроизвести ошибку на вашем локальном компьютере, просто удалите необходимый
System.Net.Http.dll
из папки Visual Studio. Это даст вам ошибку времени выполнения и, возможно, некоторые ошибки сборки. После того, как они будут исправлены, все должно работать, по крайней мере, для меня.Если вы установили
System.Net.Http
через,NuGet
проверьте, какая сборка используется, посмотрев на.csproj
версию.System.Net.Http 4.3.4
дает, например, следующую сборку:Если вы используете сервер сборки, такой как Jenkins, TeamCity или AppVey, либо отсутствующая среда выполнения также
.dll
может существовать там. В этом случае может не помочь использование NuGet-версии System.Net.Http или.dll
локальное удаление отсутствующих . Чтобы решить эту ошибку, посмотрите версию, которая не найдена, и конкретнуюPublicKeyToken
. После этого создайте перенаправление привязки в любомWeb.config
или вApp.config
зависимости от вашего проекта. В моем случае я бы хотел использовать 4.0.0.0:Хорошая ветка Github об этой проблеме:
https://github.com/dotnet/corefx/issues/22781
источник
Я только что установил
System.Net.Http
с помощью NuGet. Вы можете взять его здесь:https://www.nuget.org/packages/System.Net.Http/
В
ASP.NET MVC
проекте я работаю над целями.NET 4.6.1
. Он отлично работает на моей машине при отладкеIIS Express
с помощью Visual Studio 2019.Проблема возникла при попытке запустить приложение, развернутое в Azure. Я получал эту ошибку:
Что действительно сработало в моем случае, так это открытие файла .csproj и поиск,
System.Net.Http
как на следующем снимке экрана ...Убедитесь, что у
.csproj
файла есть версия4.1.1.3
:На
<HintPath>
самом деле указывает на..\packages
папку из NuGet, то есть, это реальная версия установлена на NuGet. После развертывания эта конкретная версия также будет восстановлена на стороне сервера, и все должно работать с перенаправлением привязки.... и поэтому перенаправление привязки должно упоминать эту конкретную версию
Web.config
следующим образом:Это устранило проблему в моем случае после пары коммитов в Azure Kudu . Веб-сайт Azure наконец-то запустился без ошибок.
источник
Что я сделал для решения проблемы, так это удалил все привязки из web.config и сделал
Update-Package -reinstall
Это удалило кучу старых привязок, которые, вероятно, не нужны, и на самом деле хорошо очистило.
источник
Я столкнулся с этой ошибкой, когда развернул веб-службу на одном из наших серверов. Проект был нацелен на .Net framework 4.7.2, который не был установлен на сервере. Установка фреймворка 4.7.2 на сервер устранила проблему.
источник
Ответ Андрея Ю привел к моему спасению. Однако рассуждения не соответствовали моему случаю. Для людей, которые находятся в том же сценарии, что и я:
Это была ошибка времени выполнения (а не времени сборки), когда сборка прошла успешно, но работала на одном компьютере, но не на сервере. Решение: - Добавлен пакет System.Net.Http. - Переименуйте файл: C: \ Program Files (x86) \ Reference Assemblies \ Microsoft \ Framework.NETFramework \ v4.7.2 \ System.Net.Http.dll (например, переименуйте в: System.Net.Http.dll.BAK) на сервер сборки.
У меня не было и до сих пор нет перенаправления сборки для этой dll
источник
Я нашел одно простое решение: понизить целевую платформу для веб-проекта до 4.6.
Я создаю клиентское и веб-приложение, клиент, имеющий .net framework 4.7.1, и веб, имеющий то же самое, и я сталкиваюсь с той же проблемой, когда я понижаю целевую платформу .net для Интернета, это работает для меня.
источник
После нескольких дней борьбы с этим я, наконец, исправил проблему .Net 4.7.2 / System.Net.Http для моего проекта. Помимо изменения файла * .csproj для таргетинга на версию фреймворка 4.7.2, мне также пришлось обновить app.config в проектах из
кому:
источник
У меня такая же проблема. В конце концов я решил это, изменив Deploy-FabricApplication.ps1 на что-то вроде этого
Я нашел 4.2.0.0 System.Net.Http.dll, то есть x64. Перед развертыванием этот сценарий копирует dll в каталог пакета и изменяет файл конфигурации, чтобы явно использовать этот файл. Я также написал блог о моих проблемах с System.Net.Http на http://gertjanvanmontfoort.blogspot.nl/2017/11/systemnethttp-dll-version-problems.html
Не забудьте заменить [ProjectName] на собственное название проекта.
Надеюсь, это поможет, не стесняйтесь спрашивать
источник
Для меня это было действительно странно. После того, как выяснилось, в чем проблема, потребовались часы отладки. Это произошло не локально, а только при использовании jenkins для сборки проекта.
У меня была небольшая библиотека, использующая dotnet standart 2.0, а основным проектом был проект WCF, основанный на обычном .NET (у меня была именно v4.6.1). Но в стартовом классе стандартной библиотеки dotnet у меня был код, который выглядел так:
Интерфейс IStaticDataConfiguration выглядит следующим образом:
Этот интерфейс находится внутри стандартной библиотеки dotnet, в то время как реализация находится вне ее (находится в проекте WCF).
Из-за пределов библиотеки я вызывал
AddStaticDataConfiguration
метод, как показано ниже:Проблема в том, что я
Func<HttpClient>
перехожу из обычного проекта .NET в стандартную библиотеку dotnet, которая по какой-то безумной причине не нравится стандарту dotnet и, возможно, думает, чтоHttpClient
это происходит из разных классов, в результате чего возникаетSystem.Net.Http 4.x.x.x
не найденное исключение. После удаления кода, чтобы не принимать aHttpClient
из обычного проекта .NET, но создавая новыйfunc
внутри самой библиотеки, он счастлив и работает нормально. Надеюсь, это может помочь кому-то другому, поскольку эта ошибка происходит по многим причинам :)источник
Мое решение было похоже на @ Raquib. Мой проект был 4.7.2 и отлично работал на моем ПК. Всякий раз, когда я развертывался на нашем сервере разработки, я получал проблему, упомянутую в вопросе. Оказывается, самая высокая версия .net на сервере была 4.6.1. Понижение версии моего проекта до 4.6.1 устранило проблему. Для меня не было возможности обновить версию сервера .net.
источник
Я считаю, что часть ответа можно найти в документации Microsoft .
Как указывает ответ @Vivek Sharma, удаление:
решил проблему в 3 таких случаях в моем приложении. Когда вы исследуете DLL с помощью Powershell, например:
Выходы
Очевидно, что перенаправление привязки на
4.2.0.0
не сработает, потому что мы выводим4.0.0.0
в корзину.Также стоит проверить GAC, чтобы увидеть, отсутствует ли сборка оттуда:
В моем случае конкретная версия также отсутствовала в GAC. Если бы DLL находилась в GAC, она должна была быть найдена в процессе привязки сборки .
источник
Сначала удалите из вашей локальной файловой системы:
Затем удалите все ссылки в проектах и добавьте ссылку 4.0.
Это решило мою проблему для меня.
источник