Дивна проблема з 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, а також на кілька пакунків "Microsoft.Diagnostics.EventFlow. *" NuGet.

Поки все компілюється без жодної помилки.

Але як тільки я потрапив у свій клас обгортки - спожитий від простої сервісної тканини без громадянства (Full .NET Framework 4.6.1) - і спробую виконати наступний рядок коду:

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

Я отримую цю дивну помилку під час виконання:

System.IO.FileNotFoundException сталося HResult = 0x80070002
Повідомлення = Не вдалося завантажити файл чи збірку 'System.Net.Http, Версія = 4.2.0.0, Культура = нейтральна, 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 бажанийConsistencyLevel)

Внутрішній виняток 1: FileNotFoundException: Не вдалося завантажити файл або збірку 'System.Net.Http, Версія = 4.0.0.0, Культура = нейтральна, PublicKeyToken = b03f5f7f11d50a3a' або одна з її залежностей. Система не може знайти вказаний файл.

У мене немає абсолютно ніякого поняття, чому збірка System.Net.Http взагалі не знайдена - у моєму проекті бібліотеки класів навіть є посилання на збірку на .Net Framework Assembly “System.Net.Http 4.0.0.0”.

Що я також не розумію, це те, що є цей дивний прив'язуючий перенаправлення до 4.2.0.0 - звідки це таке? Щоб обійти цю проблему, я спробував додати наступне переспрямування до app.config служби Service Fabric Service (яка використовує бібліотеку класів):

Але все-таки різниці немає, я все одно отримую помилку під час виконання.

Хтось має підказку? Хтось бачив таке питання?

Спасибі та з повагою, OliverB

Проблема, з якою ви стикаєтеся, пов’язана з Visual Studio, особливо 2017, який постачається разом System.Net.Http v4.2.0.0. Однак, прийнявши новий спосіб, згідно з яким будь-які посилання повинні здійснюватися через NuGet, остання версія System.Net.Http4.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 (in .csprojnot in 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, Версія = 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 () в С: \ проекти \ компанія-проект \ src \ Company.Project.BackOffice.Web \ Контролери \ Замовлення \ OrderController.cs: рядок 30 \ r \ n на lambda_method ( Закриття) \ r \ n у System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create (HttpRequestMessage request, HttpControllerDescriptor controllerDescriptor, Type controllerType) "}} Культура = нейтральна, PublicKeyToken = b03f5f7f11d50a3a 'або одна з її залежностей. Система не може знайти вказаний файл. "," ExceptionType ":" System.IO.FileNotFoundException "," StackTrace ":" в Company.Project.Service.CompanyIntegrationApiService..ctor (Uri baseAddress) \ r \ n у Company.Project .BackOffice.Web.Controllers.OrderController..ctor () в С: \ проекти \ компанія-проект \ src \ Company.Project.BackOffice.Web \ Контролери \ Замовлення \ OrderController.cs: рядок 30 \ r \ n на lambda_method ( Закриття) \ r \ n у System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create (HttpRequestMessage request, HttpControllerDescriptor controllerDescriptor, Type controllerType) "}} Культура = нейтральна, PublicKeyToken = b03f5f7f11d50a3a 'або одна з її залежностей. Система не може знайти вказаний файл. "," ExceptionType ":" System.IO.FileNotFoundException "," StackTrace ":" в Company.Project.Service.CompanyIntegrationApiService..ctor (Uri baseAddress) \ r \ n у Company.Project .BackOffice.Web.Controllers.OrderController..ctor () в С: \ проекти \ компанія-проект \ src \ Company.Project.BackOffice.Web \ Контролери \ Замовлення \ OrderController.cs: рядок 30 \ r \ n на lambda_method ( Закриття) \ r \ n у System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create (HttpRequestMessage request, HttpControllerDescriptor controllerDescriptor, Type controllerType) "}}

Коли я почав переглядати збірки, то побачив, що мій веб-проект та сервісний проект орієнтовані на різні версії для System.Net.Http.

Веб-проект:

Проект обслуговування:

Неважко подумати, що це викликано невідповідністю версій, але головне тут - подивитися на помилку The system cannot find the file specified..

Переглядаючи властивість шляху, ми можемо побачити, що веб-проект орієнтований на збірку .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 або 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/isissue/22781

Я щойно встановив System.Net.Http за допомогою NuGet. Ви можете захопити його тут:

https://www.nuget.org/packages/System.Net.Http/

ASP.NET MVCПроект я працюю по цілям .NET 4.6.1. Він прекрасно працює на моїй машині під час налагодження в IIS ExpressVisual Studio 2019.

Проблема сталася при спробі запуску програми, розгорнутої до Azure. Я отримував цю помилку:

Не вдалося завантажити файл або збірку "System.Net.Http, Версія = 4.2.0.0, Культура = нейтральна, 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 і зробив a

Update-Package -reinstall

Це вилучило купу старих прив’язок, які, ймовірно, не повинні бути там і насправді зробили хорошу чистку.

Я зіткнувся з цією помилкою, коли я розгорнув веб-службу на одному з наших серверів. Проект орієнтований на .Net Framework 4.7.2, який не був встановлений на сервері. Встановлення 4.7.2 фрейму на сервері виправило проблему.

Відповідь Андрія У призвела до мого порятунку. Однак міркування не збігалися з моєю справою. Для людей, які за тим же сценарієм, що і я:

Це була помилка виконання (не час збирання), коли збірка вдалася, але вона працювала б на одному комп’ютері, але не на сервері. Рішення: - Додано пакет System.Net.Http. - Перейменуйте файл: C: \ Program Files (x86) \ Reference Assembly \ Microsoft \ Framework.NETFramework \ v4.7.2 \ System.Net.Http.dll (наприклад, перейменуйте на: System.Net.Http.dll.BAK) на побудувати сервер.

Я не мав і досі не маю переспрямувань збірки для цього DLL

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

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

Після боротьби з цим пару днів я нарешті отримав проблему .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] власною назвою проекту

Сподіваюся, це допомагає, сміливо запитайте

Для мене було щось справді дивне. Потрібні години налагодження після того, як виявили, у чому проблема. Це сталося не локально, а лише при використанні джинкінів для створення проекту.

У мене була невелика бібліотека, що використовувала 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не знайшли винятку. Коли ви видалили код, щоб не прийняти HttpClientзвичайний проект .NET, але створити нову funcвсередині бібліотеки, вона буде задоволена і працює добре. Сподіваюся, це може допомогти комусь іншому, оскільки ця помилка трапляється з багатьох причин :)

Моє рішення було схожим на @ Raquib's. Мій проект був 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

Потім видаліть усі посилання в Projects і додайте посилання 4.0.
Це вирішило для мене мою проблему.