Impossibile caricare il file o l'assembly "System.Net.Http, Version = 2.0.0.0 nell'API Web MVC4

Ho un problema un po 'strano.
Ho sviluppato un'app con MVC 4 e la nuova API Web e funziona bene localmente. Ho installato MVC4 sul server e ho distribuito l'app. Ora ottengo il seguente errore:

Impossibile caricare il file o l'assembly "System.Net.Http, Version = 2.0.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35" o una delle sue dipendenze. La definizione del manifesto dell'assembly individuato non corrisponde al riferimento all'assembly. (Eccezione da HRESULT: 0x80131040)

Descrizione: si è verificata un'eccezione non gestita durante l'esecuzione della richiesta Web corrente. Si prega di esaminare la traccia dello stack per ulteriori informazioni sull'errore e sulla sua origine

Abbastanza divertente, la versione di System.Net.Http che ho localmente nella mia cartella del pacchetto o nella cartella ASP.NET MVC 4 \ Assemblies è 1.0.0.0. In realtà ho rimosso il riferimento a System.Net.Http dal mio progetto, ma ricevo ancora lo stesso messaggio. Sono un po 'confuso su dove ottiene il riferimento 2.0.0.0 e perché dovrebbe funzionare localmente ma non sul server.

Guardando le dipendenze nuget:

Le librerie ASP.NET WEb API Core (Beta) dipendono da System.Net.Http.Formatting.
E System.Net.Http.Formatting dipende da System.Net.Http.
Immagino sia da lì che proviene. Ma ho la versione 2.0.20126.16343 di questo pacchetto installata, è solo che la dll all'interno ha la versione 1.0.0.0

Mi sto perdendo qualcosa?

AGGIORNARE:

Questa è un'applicazione secondaria di un'altra app ASP.NET, ma l'altra è ancora basata su WebForms. Quindi, qualcosa si sta incasinando. Ma se faccio una pulizia nella sezione assembly nel web.config se non trovo nemmeno più l'app stessa.

Ho avuto lo stesso problema con la distribuzione della mia app in Appharbor. Il problema non supporta ancora .NET 4.5. Cosa ho fatto.

1. Ho cambiato il mio progetto al profilo .NET 4.0.
2. Pacchetto NuGet dell'API Web non installato.
3. Pacchetto NuGet dell'API Web (beta) installato di nuovo.
4. Verificato che il file .csproj contiene per TUTTI gli assembly di riferimento, quindi lo prenderà sempre dalla cartella Bin, invece che da GAC.

Ho riscontrato lo stesso errore durante la distribuzione di app Web precedentemente convertite (da .NET 4.5 a 4.0) su IIS 6.0.

Nella sezione runtime web.config ho trovato

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

in cui sono cambiato

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

Ora funziona come un fascino.

Il mio ha lavorato con:

Nota il reindirizzamento da 1-4 a 2.0

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

Nella cartella References del progetto dovrebbe esserci un riferimento a questa dll e la versione dovrebbe essere 2.0.0.0. Assicurati che sia impostato su Copy Local = true. Quindi assicurati che trovi la sua strada nella cartella bin della tua app server.

Questa è una delle librerie che ora è gestita da nuget. Quindi apri Nuget e assicurati che tutto sia aggiornato. E nella directory dei pacchetti dei tuoi progetti il ​​file dovrebbe essere qui: \packages\System.Net.Http.2.0.20126.16343\lib\net40

Puoi anche provare a creare una nuova app MVC4 e vedere se il file viene visualizzato per quella.

Nel mio caso l'ho risolto in un modo molto più semplice, basta dare un HintPath al riferimento al pacchetto nuget:

     <Reference Include="System.Data.Entity" />
     <Reference Include="System.Net.Http, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
       <Private>True</Private>
+      <HintPath>..\..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.dll</HintPath>
     </Reference>
     <Reference Include="System.Net.Http.WebRequest, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
       <Private>True</Private>
+      <HintPath>..\..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.WebRequest.dll</HintPath>
     </Reference>
     <Reference Include="System.Numerics" />
     <Reference Include="System.Security" />

Nel mio caso ho aggiunto involontariamente una dipendenza a System.Net.Http versione 2.1.10.0 tramite NuGet. Non sono riuscito a sbarazzarmene in NuGet Package Manager (perché altri pacchetti sembravano dipendere da esso). Tuttavia, questi pacchetti non dipendono da questa particolare versione. Ecco cosa ho fatto per eliminarlo (puoi anche usare la console NuGet (usando il parametro –force):

• Cambia la versione di Microsoft.Net.Http in packages.config da 2.1.10.0 a 2.0.0.0
• Disinstallare BCL Portability Pack in NuGet Package Manager
• Elimina manualmente le librerie dipendenti (System.Net.Http. * Che hanno la versione 2.1.10.0)
• Aggiungere un riferimento a System.Net.Http 2.0.0.0

Nella configurazione del file ho eliminato l'assembly dipendente:

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

Adesso funziona bene.

Stavo affrontando questo problema su un server di prova (Windows 2008 R2) che era presumibilmente "pronto" per la distribuzione;)

Il suggerimento era che quando ho controllato le versioni di System.net tra la mia macchina DEV e il server di distribuzione, non corrispondevano.

Risolto utilizzando i passaggi seguenti:

1. Download del programma di installazione autonomo di .NET Framework 4.5 da QUI

2. Ho eseguito il programma di installazione sulla macchina di distribuzione

Dopo l'installazione del framework, il server voleva un riavvio, così ha fatto e volla! Siamo a posto !!

Stiamo usando VS 2013, abbiamo creato una nuova API Web MVC 4 e abbiamo avuto un problema con system.net.http.dll che non era la versione corretta quando costruito sul nostro server TeamCity, ma funziona bene sui nostri computer di sviluppo locale che hanno VS 2013 installato.

Abbiamo finalmente determinato il problema.

Durante la creazione di una nuova API Web MVC 4 e la scelta del framework 4.0 sulla creazione del progetto, abbiamo riscontrato che la versione del pacchetto NuGet corretta per DLL veniva inserita in: .. \ packages \ Microsoft.Net.Http.2.0.20710.0 \ lib \ net40 \ System.Net.Http.dll

Tuttavia il file .csproj per questo progetto dice che il percorso per questo file system.net.http.dll è: .. \ packages \ Microsoft.Net.Http.2.0.30506.0 \ lib \ net40 \ System.Net.Http.dll

Quindi, quando si tenta la build, questa differenza di percorso non riesce ma trova la versione del framework corretta del file altrove sulla macchina dello sviluppatore ma non sul nostro server di build TeamCity.

Finora questa è l'unica differenza che abbiamo riscontrato. La modifica del percorso nel file .csproj e la creazione sul computer Dev locale con VS2013 funziona ancora.

Inserendolo nel controllo della versione e avendo il nostro server di build TeamCity (senza VS 2013 installato localmente) ora trova la versione corretta di .dll nella sua cartella del pacchetto NuGet per la soluzione e si compila correttamente invece di cercare un'altra versione di system.net.http .dll e trovare una versione più recente che non corrisponde al framework, causando quindi errori di compilazione.

Non sono sicuro che questo aiuti.

Controlla il percorso del file di progetto per la DLL e assicurati che corrisponda al percorso della cartella del pacchetto per la DLL.

Semplicemente semplificando le altre risposte per ciò che ha funzionato per me.

Sono andato al gestore NuGet, ho disinstallato i relativi pacchetti (nel mio caso, "Librerie client di Microsoft ASP.NET Web API 2.1" e "Json.NET") e li ho reinstallati. Sono bastati pochi clic.

Chiudi il progetto, aprilo di nuovo. Quindi, Clean Solution + Build. Per me va bene

Per la versione 2.2.15.0, ho fatto questo:

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

Ho avuto esattamente lo stesso problema! Ho dato un'occhiata alla mia scheda Avvisi in VS e ho notato che uno dei miei pacchetti nuget faceva riferimento INDIRETTAMENTE a .NETFramework Versione 4.5.0.0. Ho dovuto disinstallare questo pacchetto e quindi reinstallare la versione 4.0, ma assicurati di specificare le versioni del pacchetto che supportano 4.0 (tornerà di default a 4.5, credo se non specifichi durante l'installazione del pacchetto). Spero che questo ti aiuti!

Questo è accaduto su un server dopo la distribuzione. È stato causato da:

A) I vecchi file nella cartella bin ancora in giro che avrebbero dovuto essere eliminati

o

B) Non avere accesso in lettura alla cartella per l'utente Identità pool di applicazioni.

In altre parole, per noi questo è stato risolto correggendo i permessi sulle cartelle del sito e cancellando la cartella bin e ridistribuendo.

Ho avuto lo stesso problema con Gembox.spreadsheet.dll versione 31.

"Impossibile caricare il file o l'assembly" GemBox.Spreadsheet, Version = 39.3.30.1095, Culture = neutral, PublicKeyToken = b1b72c69714d4847 "o una delle sue dipendenze. La definizione manifest dell'assembly individuato non corrisponde al riferimento all'assembly. (Eccezione da HRESULT: 0x80131040 ) "

Ho provato quasi tutto da questi articoli e nessuno di loro ha funzionato. È stato risolto con un semplice passaggio.

Ho provato a creare progetti individuali che fondamentalmente impostassero il riferimento alla versione corretta per la dll e l'errore era completamente sparito dalla soluzione.

Va un problema simile e la direttiva menzionata in molti commenti ha funzionato bene

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

Tuttavia, è necessario assicurarsi che la copertura della vecchia versione sia sufficientemente elevata, altrimenti le versioni più recenti potrebbero non essere reindirizzate alla versione specifica necessaria e la posizione che utilizza quel riferimento più recente non funzionerà correttamente poiché il riferimento precedente è già nella directory bin.

Per questo errore (e simili) vale la pena passare attraverso NuGet Consolidate (Soluzione> Gestisci pacchetti NuGet ...) per garantire che le stesse versioni dei componenti di riferimento siano coerenti in ogni libreria di classi a cui viene fatto riferimento nella soluzione, poiché anche una versione leggermente precedente potrebbe avere dipendenze su altri componenti meno recenti. È semplice da usare in combinazione con gli aggiornamenti e può far risparmiare molto dolore.

Questo ha risolto questo problema per me e direi che è necessario acquisire familiarità con la creazione di librerie helper che fanno riferimento anche a MVC o ad altri componenti NuGet basati sul Web.