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

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

У меня есть простой проект библиотеки классов (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, Nullable 1 desiredConsistencyLevel) at Microsoft.Azure.Documents.Client.DocumentClient..ctor(Uri serviceEndpoint, String authKeyOrResourceToken, ConnectionPolicy connectionPolicy, Nullable1 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, о которой он знает.

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

• убедитесь, что любые ссылки на 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 по этому поводу, поэтому, надеюсь, они исправят это в будущем.

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

Обновить:

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

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

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

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

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

Не удалось загрузить файл или сборку System.Net.Http, Version = 4.2.0.0, Culture = нейтральный, 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 ( Закрытие) \ r \ n в System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create (запрос HttpRequestMessage, HttpControllerDescriptor controllerDescriptor, тип controllerType) "}} Культура = нейтральный, 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 ( Закрытие) \ r \ n в System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create (запрос HttpRequestMessage, HttpControllerDescriptor controllerDescriptor, тип controllerType) "}} Культура = нейтральный, 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 ( Закрытие) \ r \ n в System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create (запрос HttpRequestMessage, HttpControllerDescriptor controllerDescriptor, тип controllerType) "}}

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

Веб-проект:

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

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

Чтобы воспроизвести ошибку на вашем локальном компьютере, просто удалите необходимый 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 или AppVey, либо отсутствующая среда выполнения также .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

Я только что установил 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, Version = 4.2.0.0, Culture = нейтральный, PublicKeyToken = b03f5f7f11d50a3a или одну из их зависимостей.

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

Убедитесь, что у .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 наконец-то запустился без ошибок.

Что я сделал для решения проблемы, так это удалил все привязки из 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 в проектах из

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

кому:

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

У меня такая же проблема. В конце концов я решил это, изменив 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] на собственное название проекта.

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

Для меня это было действительно странно. После того, как выяснилось, в чем проблема, потребовались часы отладки. Это произошло не локально, а только при использовании 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метод, как показано ниже:

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.x.x.xне найденное исключение. После удаления кода, чтобы не принимать a HttpClientиз обычного проекта .NET, но создавая новый funcвнутри самой библиотеки, он счастлив и работает нормально. Надеюсь, это может помочь кому-то другому, поскольку эта ошибка происходит по многим причинам :)

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

Я считаю, что часть ответа можно найти в документации Microsoft .

Когда вы создаете классическое приложение в Visual Studio, ориентированное на .NET Framework 4.5.1 или более позднюю версию, приложение использует автоматическое перенаправление привязки.

Как указывает ответ @Vivek Sharma, удаление:

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

решил проблему в 3 таких случаях в моем приложении. Когда вы исследуете DLL с помощью Powershell, например:

 ([system.reflection.assembly]::loadfile("C:\MyApp\bin\System.Net.Sockets.dll")).FullName

Выходы

System.Net.Sockets, версия = 4.0.0.0

Очевидно, что перенаправление привязки на 4.2.0.0не сработает, потому что мы выводим 4.0.0.0в корзину.

Также стоит проверить GAC, чтобы увидеть, отсутствует ли сборка оттуда:

 gacutil -l System.Net.Sockets

В моем случае конкретная версия также отсутствовала в GAC. Если бы DLL находилась в GAC, она должна была быть найдена в процессе привязки сборки .

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

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

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