Странная проблема с System.Net.Http 4.2.0.0 не найдена

У меня странная проблема, которая сводит меня с ума...

У меня есть простой проект библиотеки классов (Полная.NET Framework, 4.6.1) с классом-оболочкой для функциональности вокруг базы данных Cosmos. Поэтому я добавил к этому проекту пакет NuGet пакета "Microsoft.Azure.DocumentDB" 1.19.1. Кроме этого, у меня есть ссылка на NuGet Package 10.0.3 Newtonsoft.Json, а также на пару пакетов NuGet для Microsoft.Diagnostics.EventFlow. *.

Пока все компилируется без ошибок.

Но как только я ударил мой класс-оболочку - потребляемый простой Service Fabric Stateless Service (Полная.NET Framework 4.6.1) - и попробуйте выполнить следующую строку кода:

_docClient = new DocumentClient(new Uri(cosmosDbEndpointUrl), cosmosDbAuthKey);

Я получаю эту странную ошибку во время выполнения:

Исключено System.IO.FileNotFoundException HResult = 0x80070002
Message = Не удалось загрузить файл или сборку "System.Net.Http, Version = 4.2.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a" или одну из его зависимостей. Система не может найти указанный файл.
Source = StackTrace: at Microsoft.Azure.Documents.Client.DocumentClient.Initialize(Uri serviceEndpoint, ConnectionPolicy connectionPolicy, Nullable 1 desiredConsistencyLevel) at Microsoft.Azure.Documents.Client.DocumentClient..ctor(Uri serviceEndpoint, String authKeyOrResourceToken, ConnectionPolicy connectionPolicy, Nullable 1 wishConsistencyLevel)

Внутреннее исключение 1: FileNotFoundException: не удалось загрузить файл или сборку "System.Net.Http, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a" или одна из его зависимостей. Система не может найти указанный файл.

Я совершенно не понимаю, почему сборка System.Net.Http не найдена вообще - в моем проекте библиотеки классов есть ссылка на сборку.Net Framework Assembly "System.Net.Http 4.0.0.0".

То, что я также не понимаю, заключается в том, что существует такая странная переадресация ссылок на 4.2.0.0 - откуда это происходит? Чтобы обойти эту проблему, я попытался добавить следующую перенаправление в app.config службы Fabric Service (которая использует библиотеку классов):

Но все равно никакой разницы, я все еще получаю ошибку во время выполнения.

Кто-нибудь знает? Кто-нибудь видел такую проблему?

Спасибо и приветствую, OliverB

Ответ 1

Проблема, с которой вы сталкиваетесь, связана с Visual Studio, особенно 2017 года, которая поставляется с System.Net.Http v4.2.0.0. Однако, принимая новый способ, посредством которого любые ссылки должны быть сделаны через NuGet, последняя версия System.Net.Http которая является 4.3.3, содержит версию 4.1.1.2 dll.

Проблема в том, что VS во время сборки, а также во время выполнения будет игнорировать вашу ссылку и будет пытаться ссылаться на DLL, о которой он знает.

Как это исправить:

  • убедитесь, что любые ссылки на System.Net.Http выполняются через NuGet
  • Ошибки времени сборки: измените расширение System.Net.Http.dll (или переместите его куда-нибудь еще... в основном избавьтесь от него), которое поставляется с VS 2017 (c:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\); если у вас другая версия, то путь будет немного отличаться, хотя и не сильно
  • Ошибки времени выполнения: добавить перенаправление привязки сборки

Если вы посмотрите онлайн в Google, вы обнаружите несколько открытых проблем с Microsoft по этому поводу, так что, надеюсь, они исправят это в будущем.

Надеюсь это поможет.

Обновить:

Рассматривая поиск некоторых постоянных исправлений для этой проблемы для работы с агентами сборки, заметил, что при .csproj на новую модель NuGet PackageReference (в .csproj не в packages.config), как правило, работает лучше. Здесь ссылка на руководство о том, как сделать это обновление: https://docs.microsoft.com/en-us/nuget/reference/migrate-packages-config-to-package-reference

Ответ 2

Удаление перенаправления привязки работало для меня, вы можете попробовать удалить его:

<bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" />

Ответ 3

Дополнение к ответу @AndreiU уже дал и как локально воспроизводить ошибки времени выполнения.

При развертывании в Azure, а не локально, я получил ошибку времени выполнения ниже.

{"Message": "Произошла ошибка.", "ExceptionMessage": "Произошла ошибка при попытке создать контроллер типа 'OrderController'. Убедитесь, что контроллер имеет открытый конструктор без параметров.", "ExceptionType": "System.InvalidOperationException", "StackTrace": "в System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create (запрос HttpRequestMessage, HttpControllerDescriptor controllerDescriptor, тип controllerType)\r\n.troltrolontrolControllerControllerControllerControllerControllerControllerControllerControllerControllerControllerControllerControllerControllerControllerControllerControllerControllerControllerControllerControllerControllerControllerControlControllerControllerControllerControllerControllerControllerControllerControllerControllerControllerControllerControllerControllerControl_ControllerControl_ControllerControl_ControllerControl_Cr.dll используется для системных файлов. Запрос HttpRequestMessage)\r\n в System.Web.Http.Dispatcher.HttpControllerDispatcher.d__1.MoveNext() "," InnerException ": {" Message ":" Произошла ошибка. "," ExceptionMessage ":" Не удалось загрузить файл или сборка 'System.Net.Http, версия = 4.2.0.0, культура = нейтральная, PublicKeyToken = b03f5f7f11d50a3a' или одна из ее зависимостей. Система не может найти указанный файл. "," ExceptionType ":" System.IO.FileNotFoundException "," StackTrace ":" в Company.Project.Service.CompanyIntegrationApiService ..ctor(Uri baseAddress)\r\n в Company.Project.BackOffice.Web.Controllers.OrderController..ctor() в C:\projects\company-project\src\Company.Project.BackOffice.Web\Controllers\Order\OrderController.cs: строка 30\r\n в lambda_method (Closure)\r\n в System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create (запрос HttpRequestMessage, HttpControllerDescriptor controllerDescriptor, тип controllerType)

Когда я начал смотреть на сборки, я увидел, что мой веб-проект и сервисный проект нацелены на разные версии System.Net.Http.

Веб-проект:

enter image description here

Сервисный проект:

enter image description here

Легко представить, что это вызвано несоответствием версий, но ключом здесь является поиск ошибки The system cannot find the file specified. ,

Изучив свойство path, мы увидим, что веб-проект нацелен на сборку .Net Framework, а служба нацелена на сборку из Visual Studio 2017. Поскольку на сервере не установлена Visual Studio 2017, произойдет ошибка времени выполнения.

Веб-путь:

C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.Net.Http.dll

Путь обслуживания:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.Net.Http.dll

Что-то простое, например, установив Copy Local в true может решить проблему, но не во всех случаях.

enter image description here

Чтобы воспроизвести ошибку на локальном компьютере, просто удалите необходимый System.Net.Http.dll из определенной папки Visual Studio. Это даст вам ошибку времени выполнения и, возможно, некоторые ошибки сборки. После того, как они исправлены, все должно работать, по крайней мере, для меня.

Если вы установили System.Net.Http через NuGet проверьте, какая сборка используется, посмотрев версию .csproj. System.Net.Http 4.3.4 дает следующую сборку, например:

<Reference Include="System.Net.Http, Version=4.1.1.3, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
  <HintPath>..\packages\System.Net.Http.4.3.4\lib\net46\System.Net.Http.dll</HintPath>
  <Private>True</Private>
  <Private>True</Private>
</Reference>

Если вы используете сервер сборки, такой как Jenkins, TeamCity или AppVeyor, там также может существовать отсутствующая среда выполнения .dll. В этом случае может не помочь использование NuGet-версии System.Net.Http или удаление отсутствующего .dll локально. Чтобы устранить эту ошибку, посмотрите на версию, которая не найдена, и на конкретный PublicKeyToken. После этого создайте перенаправление привязки в Web.config или App.config зависимости от вашего проекта. В моем случае я хотел бы использовать вместо 4.0.0.0:

<dependentAssembly>
  <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.0.0.0" />
</dependentAssembly>

Хорошая ветка Github о проблеме:

https://github.com/dotnet/corefx/issues/22781

Ответ 4

Я столкнулся с этой ошибкой, когда развернул веб-сервис на одном из наших серверов. Проект нацелен на.Net framework 4.7.2, который не был установлен на сервере. Установка платформы 4.7.2 на сервере устранила проблему.

Ответ 5

То, что я сделал, чтобы исправить проблему, удалил все привязки из web.config и сделал

Update-Package -reinstall

Это удалило кучу старых привязок, которые, вероятно, не должны быть там, и фактически сделало хорошую уборку.

Ответ 6

Одно простое решение, которое я нашел, - понизить целевую платформу для веб-проекта до 4.6.

Я создаю клиент и веб-приложение, клиент, имеющий .net Framework 4.7.1, и веб-сайт, имеющий то же самое, и я сталкиваюсь с той же проблемой, когда я понижаю целевой .net Framework для веб-сайтов, это работает для меня.

Ответ 7

Я только что установил 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. Я получаю эту ошибку:

Не удалось загрузить файл или сборку 'System.Net.Http, версия = 4.2.0.0, культура = нейтральная, PublicKeyToken = b03f5f7f11d50a3a' или одна из ее зависимостей.

В моем случае действительно работало открытие файла .csproj и поиск System.Net.Http как на следующем скриншоте...

enter image description here

.csproj файл .csproj имеет версию 4.1.1.3:

<Reference Include="System.Net.Http, Version=4.1.1.3, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">

<HintPath> фактически указывает на папку ..\packages от Nuget, то есть это реальная версия, установленная Nuget. После развертывания эта конкретная версия также будет восстановлена на стороне сервера, и все должно работать с перенаправлением привязки.

... и, таким образом, перенаправление привязки должно упоминать эту конкретную версию в Web.config следующим образом:

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.1.1.3" />
</dependentAssembly>

Это исправило проблему в моем случае после пары коммитов в Azure Kudu. Сайт Azure наконец-то запустился без ошибок.

Ответ 8

У меня такая же проблема. В конце концов я решил это, изменив Deploy-FabricApplication.ps1 на что-то вроде этого

$binFolder = "$LocalFolder\..\..\..\..\Bin"

$httpDllLocation = "$binFolder\System.Net.Http.dll"
$codeFolder = "$ApplicationPackagePath\[ProjectName].ServicesPkg\Code"
$configFile = "$codeFolder\[ProjectName].Services.exe.config"

Copy-Item $httpDllLocation -Destination $codeFolder 

$appConfig = [xml](cat $configFile)
$appConfig.configuration.runtime.assemblyBinding.dependentAssembly | foreach {

    $name = $_.assemblyIdentity.name
    #Write $name
    if($name -eq 'System.Net.Http')
    {
        Write 'System.Net.Http changed'

        $_.bindingRedirect.newVersion = '4.2.0.0'
    }
}
$appConfig.Save($configFile)

Я нашел 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] своим собственным именем проекта

Надеюсь, это поможет, не стесняйтесь спрашивать

Ответ 9

Я использовал System.Net.Http чтобы отправить запрос на проверку токена Google Captcha с помощью Owin, и я получал эту ошибку. Единственное решение, которое работало идеально, это удаление заявки HttpClient и добавление RestSharp.

Ответ 10

Для меня было что-то действительно странное. Нужны часы отладки после того, как выяснилось в чем проблема. Это происходило не локально, а только при использовании jenkins для создания проекта.

У меня была небольшая библиотека, использующая dotnet standart 2.0, и основным проектом был WCF-проект, основанный на обычном .NET (мой был специально v4.6.1). Но в классе запуска стандартной библиотеки dotnet у меня был код, который выглядел так:

public static class CoreModule
{
    public static IServiceCollection AddStaticDataConfiguration(
        this IServiceCollection services, Func<IServiceProvider, IStaticDataConfiguration>  staticDataConfiguration) 
    {  
        services.TryAddSingleton(staticDataConfiguration);
        services.TryAddSingleton<Func<HttpClient>>(x =>
        {
            var configuration = staticDataConfiguration(x);

            return configuration.ClientResolver ?? (() => new HttpClient());
        });
        return services;
    }
}

Интерфейс IStaticDataConfiguration выглядит следующим образом:

public interface IStaticDataConfiguration
{
    //..... some stuff

    Func<HttpClient> ClientResolver { get; set; }
}  

Этот интерфейс находится внутри стандартной библиотеки dotnet, а реализация находится за ее пределами (она находится в проекте WCF).

Из-за пределов библиотеки я AddStaticDataConfiguration метод AddStaticDataConfiguration как AddStaticDataConfiguration ниже:

serviceCollection.AddStaticDataConfiguration(p =>
{
    var staticDataConfig = p.GetService<IStaticDataConfiguration>();
    return new StaticDataProviderConfiguration
    {
        //...some other stuff
        ClientResolver = () => restRequestFactory.GetInstrumentedClient("StaticDataService") //this returns an HttpClient
    };
});

Проблема в том, что я передаю Func<HttpClient> из обычного проекта .NET в стандартную библиотеку dotnet, которая по какой-то сумасшедшей причине не нравится стандарту dotnet и, возможно, он думает, что HttpClient происходит из разных классов, в результате выбрасывая System.Net.Http 4.xxx не найдено исключение. Когда удалили код не принимать HttpClient от обычного проекта .NET, но создание нового func внутри самой его счастливым и работает отлично библиотеки. Надеюсь, что это может помочь кому-то еще, так как эта ошибка происходит по многим причинам :)

Ответ 11

Мое решение было похоже на @Raquib's. Мой проект был 4.7.2 и отлично работал на моем ПК. Всякий раз, когда я развертывался на нашем сервере разработки, я упоминал проблему, упомянутую в вопросе. Оказывается, самая высокая версия .net на сервере была 4.6.1. Понижение моего проекта до 4.6.1 решило проблему. Обновление версии сервера .net не было для меня вариантом.

Ответ 12

Сначала удалите из вашей локальной файловой системы:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\Syste.Net.Http.dll

Затем удалите все ссылки в проектах и добавьте ссылку 4.0.
Это решило мою проблему для меня.

Ответ 13

После нескольких дней борьбы с этим я наконец-то исправил проблему .Net 4.7.2/System.Net.Http для своего проекта. В дополнение к изменению файла *.csproj для целевой платформы версии 4.7.2 мне также пришлось обновить app.config в проектах из

<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1" />

в:

<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7.2" />