Strano problema con System.Net.Http 4.2.0.0 non trovato

Ho uno strano problema, che mi fa impazzire ...

Ho un semplice progetto di libreria di classi (.NET Framework completo, 4.6.1) con una classe wrapper per funzionalità attorno a Cosmos DB. Pertanto ho aggiunto il pacchetto NuGet 1.19.1 "Microsoft.Azure.DocumentDB" a questo progetto. Oltre a questo, ho un riferimento al pacchetto NuGet "Newtonsoft.Json" 10.0.3, nonché a un paio di pacchetti NuGet "Microsoft.Diagnostics.EventFlow. *".

Finora, tutto viene compilato senza errori.

Ma non appena raggiungo la mia classe wrapper - consumata da un semplice servizio stateless di Service Fabric (.NET Framework completo 4.6.1) - e provo a eseguire la seguente riga di codice:

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

Ottengo questo strano errore in fase di esecuzione:

Si è verificata System.IO.FileNotFoundException HResult = 0x80070002
Message = Impossibile caricare il file o l'assembly 'System.Net.Http, Version = 4.2.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a' o una delle sue dipendenze. Il sistema non trova il file specificato.
Origine = StackTrace: in 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 wantedConsistencyLevel)

Eccezione interna 1: FileNotFoundException: impossibile caricare il file o l'assembly "System.Net.Http, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a" o una delle sue dipendenze. Il sistema non trova il file specificato.

Non ho assolutamente idea del motivo per cui l'assembly System.Net.Http non viene trovato affatto - c'è anche un riferimento all'assembly nel mio progetto di libreria di classi per l'assembly .Net Framework "System.Net.Http 4.0.0.0".

Quello che inoltre non capisco è che c'è questo strano reindirizzamento vincolante a 4.2.0.0 - da dove viene quello? Per aggirare questo problema, ho provato ad aggiungere il seguente reindirizzamento all'app.config del servizio Service Fabric (che sta consumando la libreria di classi):

Ma ancora nessuna differenza, ricevo ancora l'errore in fase di esecuzione.

Qualcuno ha un'idea? Qualcuno ha visto un problema del genere?

Grazie e saluti, OliverB

Il problema che stai affrontando è relativo a Visual Studio, in particolare al 2017 che viene fornito con System.Net.Http v4.2.0.0. Tuttavia, adottando il nuovo modo in cui tutti i riferimenti dovrebbero essere eseguiti tramite NuGet, l'ultima versione della System.Net.Httpquale è la 4.3.3 contiene la versione dll 4.1.1.2.

Il problema è che VS in fase di compilazione e anche in fase di esecuzione ignorerà il tuo riferimento e proverà a fare riferimento alla DLL di cui è a conoscenza.

Come sistemarlo:

• assicurarsi che tutti i riferimenti a System.Net.Http vengano eseguiti tramite NuGet
• Errori in fase di compilazione: modificare l'estensione di System.Net.Http.dll (o spostarlo altrove ... in pratica eliminarlo) fornito con VS 2017 ( c:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\); se hai una versione diversa, il percorso sarà leggermente diverso, non molto però

• Errori di runtime: aggiungere un reindirizzamento dell'associazione di assembly

Se guardi online su Google troverai alcuni problemi aperti con Microsoft su questo, quindi si spera che risolveranno questo problema in futuro.

Spero che questo ti aiuti.

Aggiornare:

Quando si cerca di trovare alcune correzioni permanenti per questo problema per funzionare sugli agenti di compilazione, si è notato che se si esegue la migrazione al nuovo modello NuGet PackageReference (in .csprojnon in packages.config) tende a funzionare meglio. Ecco un collegamento alla guida su come eseguire questo aggiornamento: https://docs.microsoft.com/en-us/nuget/reference/migrate-packages-config-to-package-reference

La rimozione del reindirizzamento vincolante ha funzionato per me, puoi provare a rimuoverlo:

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

Un'aggiunta alla risposta che @AndreiU ha già dato e come riprodurre localmente gli errori di runtime.

Ho ricevuto l'errore di runtime di seguito durante la distribuzione in Azure, non localmente.

Impossibile caricare il file o l'assembly "System.Net.Http, Version = 4.2.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a" o una delle sue dipendenze. Il sistema non riesce a trovare il file specificato. "," ExceptionType ":" System.IO.FileNotFoundException "," StackTrace ":" in Company.Project.Service.CompanyIntegrationApiService..ctor (Uri baseAddress) \ r \ n in Company.Project .BackOffice.Web.Controllers.OrderController..ctor () in C: \ projects \ company-project \ src \ Company.Project.BackOffice.Web \ Controllers \ Order \ OrderController.cs: riga 30 \ r \ n su lambda_method ( Closure) \ r \ n in System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create (richiesta HttpRequestMessage, HttpControllerDescriptor controllerDescriptor, Type controllerType) "}} Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a 'o una delle sue dipendenze. Il sistema non riesce a trovare il file specificato. "," ExceptionType ":" System.IO.FileNotFoundException "," StackTrace ":" in Company.Project.Service.CompanyIntegrationApiService..ctor (Uri baseAddress) \ r \ n in Company.Project .BackOffice.Web.Controllers.OrderController..ctor () in C: \ projects \ company-project \ src \ Company.Project.BackOffice.Web \ Controllers \ Order \ OrderController.cs: riga 30 \ r \ n su lambda_method ( Closure) \ r \ n in System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create (richiesta HttpRequestMessage, HttpControllerDescriptor controllerDescriptor, Type controllerType) "}} Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a 'o una delle sue dipendenze. Il sistema non riesce a trovare il file specificato. "," ExceptionType ":" System.IO.FileNotFoundException "," StackTrace ":" in Company.Project.Service.CompanyIntegrationApiService..ctor (Uri baseAddress) \ r \ n in Company.Project .BackOffice.Web.Controllers.OrderController..ctor () in C: \ projects \ company-project \ src \ Company.Project.BackOffice.Web \ Controllers \ Order \ OrderController.cs: riga 30 \ r \ n su lambda_method ( Closure) \ r \ n in System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create (richiesta HttpRequestMessage, HttpControllerDescriptor controllerDescriptor, Type controllerType) "}}

Quando ho iniziato a guardare gli assembly, ho notato che il mio progetto Web e il progetto di servizio erano destinati a versioni diverse System.Net.Http .

Progetto web:

Progetto di servizio:

È facile pensare che ciò sia causato da una mancata corrispondenza nelle versioni, ma la chiave qui è guardare l'errore The system cannot find the file specified. .

Osservando la proprietà path possiamo vedere che il progetto web è destinato a un assembly .Net Framework mentre il servizio è destinato a un assembly da Visual Studio 2017. Poiché sul server non è installato Visual Studio 2017, si verificherà l'errore di runtime.

Percorso web:

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

Percorso di servizio:

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

Qualcosa di semplice come impostazione Copy Localper truepoter risolvere il problema, ma non in tutti i casi.

Per riprodurre l'errore sulla tua macchina locale, rimuovi semplicemente il file System.Net.Http.dll dalla cartella specifica di Visual Studio. Questo ti darà l'errore di runtime e probabilmente alcuni errori di compilazione. Dopo che questi sono stati riparati, tutto dovrebbe funzionare, almeno per me.

Se hai installato System.Net.Httptramite NuGetverifica quale assembly viene utilizzato guardando la .csprojversione. System.Net.Http 4.3.4fornisce il seguente assembly per esempio:

<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>

Se utilizzi un server di compilazione come Jenkins, TeamCity o AppVey o il runtime mancante .dllpotrebbe esistere anche lì. In questo caso potrebbe non essere utile usare la versione NuGet di System.Net.Http o eliminare .dlllocalmente il file mancante . Per risolvere questo errore guarda la versione che non è stata trovata e lo specifico PublicKeyToken. Successivamente crea un reindirizzamento vincolante in uno Web.configo in App.configbase al tuo progetto. Nel mio caso vorrei invece utilizzare 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>

Un buon thread Github sul problema:

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

Ho appena installato System.Net.Httputilizzando NuGet. Puoi afferrare qui:

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

Il ASP.NET MVCprogetto su cui sto lavorando su obiettivi .NET 4.6.1. Funziona perfettamente sulla mia macchina durante il debug IIS Expresscon Visual Studio 2019.

Il problema si è verificato durante il tentativo di eseguire l'applicazione distribuita in Azure. Ho ricevuto questo errore:

Impossibile caricare il file o l'assembly "System.Net.Http, Version = 4.2.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a" o una delle sue dipendenze.

Quello che ha funzionato davvero nel mio caso è stato l'apertura del file .csproj e la ricerca di System.Net.Httpcome nello screenshot seguente ...

Controlla che il .csprojfile abbia la versione 4.1.1.3:

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

In <HintPath>realtà punta alla ..\packagescartella di Nuget, ovvero questa è la versione reale installata da Nuget. Una volta distribuita, questa specifica versione verrà ripristinata anche sul lato server e tutto dovrebbe funzionare con un reindirizzamento bind.

... e così il reindirizzamento vincolante dovrebbe menzionare questa versione specifica in Web.configquesto modo:

<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>

Questo ha risolto il problema nel mio caso dopo un paio di commit su Azure Kudu . Il sito Web di Azure è stato finalmente avviato senza errori.

Quello che ho fatto per risolvere il problema è stato rimosso tutti i collegamenti da web.config e ho eseguito un file

Update-Package -reinstall

Questo ha rimosso un mucchio di vecchi attacchi che probabilmente non avevano bisogno di essere lì e in realtà ha fatto una buona pulizia.

Ho riscontrato questo errore quando ho distribuito un servizio Web su uno dei nostri server. Il progetto mirava a .Net framework 4.7.2, che non era installato sul server. L'installazione del framework 4.7.2 sul server ha risolto il problema.

La risposta di Andrei U ha portato alla mia salvezza. Tuttavia, il ragionamento non corrispondeva al mio caso. Per le persone che si trovano nella mia stessa situazione:

È stato un errore di runtime (non in fase di compilazione), in cui la compilazione è riuscita, ma avrebbe funzionato su un computer, ma non sul server. Soluzione: - Aggiunto pacchetto System.Net.Http. - Rinomina file: C: \ Program Files (x86) \ Reference Assemblies \ Microsoft \ Framework.NETFramework \ v4.7.2 \ System.Net.Http.dll (es. Rinomina in: System.Net.Http.dll.BAK) sul build server.

Non avevo e ancora non ho reindirizzamenti di assembly per questa dll

Una semplice soluzione che ho trovato che esegua il downgrade del framework di destinazione per il progetto web a 4.6.

Creo client e applicazioni web, client con .net framework 4.7.1 e web con lo stesso problema e sto affrontando lo stesso problema, quando eseguo il downgrade .net framework di destinazione per il web funziona per me.

Dopo aver lottato con questo per un paio di giorni ho finalmente risolto il problema .Net 4.7.2 / System.Net.Http per il mio progetto. Oltre a modificare il file * .csproj per targetizzare la versione del framework 4.7.2, ho dovuto anche aggiornare app.config nei progetti da

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

per:

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

Ho avuto lo stesso problema. Alla fine l'ho risolto cambiando Deploy-FabricApplication.ps1 in qualcosa di simile

$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)

Ho trovato un 4.2.0.0 System.Net.Http.dll che è x64. Prima di distribuire questo script, copia la dll nella directory del pacchetto e modifica il file di configurazione per utilizzare esplicitamente questo file. Ho anche scritto un blog sui miei problemi System.Net.Http su http://gertjanvanmontfoort.blogspot.nl/2017/11/systemnethttp-dll-version-problems.html

Non dimenticare di sostituire [ProjectName] con il nome del tuo progetto

Spero che questo aiuti, sentiti libero di chiedere

Per me è stato qualcosa di veramente strano. Sono state necessarie ore di debug dopo aver scoperto qual era il problema. Non è successo localmente ma solo quando si utilizzava jenkins per costruire il progetto.

Avevo una piccola libreria che utilizzava dotnet standard 2.0 e il progetto principale era il progetto WCF che si basa sul normale .NET (il mio era specificamente v4.6.1). Ma nella classe di avvio della libreria dotnet standard avevo del codice simile a questo:

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;
    }
}

L'interfaccia di IStaticDataConfiguration ha il seguente aspetto:

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

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

Questa interfaccia risiede all'interno della libreria dotnet standart mentre l'implementazione è all'esterno di essa (si trova nel progetto WCF).

Dall'esterno della libreria stavo chiamando il AddStaticDataConfigurationmetodo come di seguito:

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

Il problema è che sto passando Func<HttpClient>da un normale progetto .NET a una libreria dotnet standart che per qualche folle ragione dotnet standart non piace e forse pensa HttpClientprovenga da classi diverse, di conseguenza lanciando System.Net.Http 4.x.x.xun'eccezione non trovata. Quando viene rimosso il codice per non accettare un HttpClientda un normale progetto .NET ma crearne uno nuovo funcall'interno della libreria stessa è felice e funziona bene. Spero che questo possa aiutare qualcun altro poiché questo errore si verifica per tanti motivi :)

La mia soluzione era simile a quella di @ Raquib. Il mio progetto era 4.7.2 e ha funzionato perfettamente sul mio PC. Ogni volta che eseguivo il deployment sul nostro server di sviluppo, ricevevo il problema menzionato nella domanda. Si è scoperto che la versione .net più recente sul server era la 4.6.1. Il downgrade del mio progetto a 4.6.1 ha risolto il problema. L'aggiornamento della versione .net del server non era un'opzione per me.

Credo che parte della risposta si possa trovare nella documentazione di Microsoft .

Quando crei un'app desktop in Visual Studio destinata a .NET Framework 4.5.1 o versione successiva, l'app usa il reindirizzamento automatico dell'associazione.

Come sottolinea la risposta di @Vivek Sharma, rimuovendo:

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

ha risolto il problema in 3 casi simili nella mia app. Quando esamini la DLL con Powershell, ad esempio:

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

Uscite

System.Net.Sockets, versione = 4.0.0.0

Chiaramente un reindirizzamento vincolante a 4.2.0.0non funzionerà perché stiamo eseguendo 4.0.0.0l' output nel cestino.

Vale anche la pena controllare il GAC per vedere se l'assembly manca anche da lì:

 gacutil -l System.Net.Sockets

Nel mio caso la versione particolare mancava anche dal GAC. Se la DLL si trovava nel GAC, avrebbe dovuto essere trovata nel processo di associazione dell'assembly .

Prima elimina dal tuo filesystem locale:

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

Quindi rimuovere tutti i riferimenti in Progetti e aggiungere il riferimento 4.0.
Questo mi ha risolto il problema.