Impossible de charger le fichier ou l'assembly 'System.Net.Http, Version = 2.0.0.0 dans l'API Web MVC4

J'ai un problème un peu étrange.
J'ai développé une application avec MVC 4 et la nouvelle API Web et cela fonctionne très bien localement. J'ai installé MVC4 sur le serveur et déployé l'application. Maintenant, j'obtiens l'erreur suivante:

Impossible de charger le fichier ou l'assembly 'System.Net.Http, Version = 2.0.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35' ou l'une de ses dépendances. La définition de manifeste de l'assembly localisé ne correspond pas à la référence d'assembly. (Exception de HRESULT: 0x80131040)

Description: une exception non gérée s'est produite lors de l'exécution de la requête Web actuelle. Veuillez consulter la trace de la pile pour plus d'informations sur l'erreur et son origine

Assez drôle, la version de System.Net.Http que j'ai localement dans mon dossier de package ou dans le dossier ASP.NET MVC 4 \ Assemblies est 1.0.0.0. En fait, j'ai supprimé la référence à System.Net.Http de mon projet, mais je reçois toujours le même message. Je ne sais pas trop d'où il tire la référence 2.0.0.0 et pourquoi cela fonctionnerait localement mais pas sur le serveur.

En regardant les dépendances nuget:

Les bibliothèques principales de l'API WEb ASP.NET (bêta) dépendent de System.Net.Http.Formatting.
Et System.Net.Http.Formatting dépend de System.Net.Http.
Je suppose que c'est de là que cela vient. Mais j'ai la version 2.0.20126.16343 de ce paquet installée, c'est juste que la dll à l'intérieur a la version 1.0.0.0

Est-ce que je manque quelque chose?

METTRE À JOUR:

Il s'agit d'une sous-application d'une autre application ASP.NET, mais l'autre est toujours basée sur WebForms. Donc, quelque chose ne va pas. Mais si je nettoie sous la section assembly du web.config, je ne trouve même plus l'application elle-même.

J'ai eu le même problème avec le déploiement de mon application sur appharbor. Le problème, il ne prend pas encore en charge .NET 4.5. Ce que j'ai fait.

1. J'ai basculé mon projet vers le profil .NET 4.0.
2. Package NuGet de l'API Web désinstallé.
3. Installation du package NuGet de l'API Web (bêta) à nouveau.
4. Vérifié que le fichier .csproj contient pour TOUS les assemblys référencés, donc il le prendra toujours du dossier Bin, au lieu de GAC.

J'ai eu la même erreur lors du déploiement de l'application Web précédemment convertie (de .NET 4.5 à 4.0) sur IIS 6.0.

Dans la section d' exécution web.config , j'ai trouvé

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

que j'ai changé en

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

Fonctionne maintenant comme du charme.

Le mien a travaillé avec:

Notez la redirection de 1-4 vers 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>

Dans le dossier Références de votre projet, il doit y avoir une référence à cette DLL et la version doit être 2.0.0.0. Assurez-vous que ce paramètre est défini sur Copy Local = true. Et puis assurez-vous qu'il trouve son chemin vers le dossier bin de votre application serveur.

C'est l'une des bibliothèques qui est désormais gérée par nuget. Alors ouvrez Nuget et assurez-vous que tout est à jour. Et dans le répertoire des packages de vos projets, le fichier doit être ici: \packages\System.Net.Http.2.0.20126.16343\lib\net40

Vous pouvez également essayer de créer une nouvelle application MVC4 et voir si le fichier apparaît pour celle-ci.

Dans mon cas, je l'ai corrigé d'une manière beaucoup plus simple, il suffit de donner un HintPath à la référence au paquet 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" />

Dans mon cas, j'ai involontairement ajouté une dépendance à System.Net.Http version 2.1.10.0 via NuGet. Je ne pouvais pas m'en débarrasser dans le gestionnaire de packages NuGet (car d'autres packages semblaient en dépendre). Cependant, ces packages ne dépendent pas de cette version particulière. Voici ce que j'ai fait pour m'en débarrasser (vous pouvez également utiliser la console NuGet à la place (en utilisant le paramètre –force):

• Changer la version de Microsoft.Net.Http dans packages.config de 2.1.10.0 à 2.0.0.0
• Désinstaller BCL Portability Pack dans NuGet Package Manager
• Se débarrasser manuellement des bibliothèques dépendantes (System.Net.Http. * Qui ont la version 2.1.10.0)
• Ajouter une référence à System.Net.Http 2.0.0.0

Dans la configuration du fichier, j'ai supprimé l'assemblage dépendant:

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

Maintenant ça marche bien.

J'étais confronté à ce problème sur un serveur de test (Windows 2008 R2) qui était censé être "prêt" pour le déploiement;)

L'indice était que lorsque j'ai vérifié les versions de System.net entre ma machine DEV et le serveur de déploiement, elles ne correspondaient pas.

Correction en utilisant les étapes ci-dessous:

1. Programme d'installation autonome de .NET Framework 4.5 téléchargé ICI

2. Ran le programme d'installation sur la machine de déploiement

Après l'installation du framework, le serveur voulait un redémarrage, tout comme ça et volla! Nous sommes prêts à partir !!

Nous utilisons VS 2013, avons créé une nouvelle API Web MVC 4 et avons eu un problème avec le system.net.http.dll n'étant pas la version correcte lorsqu'il est construit sur notre serveur TeamCity, mais il se construit bien sur nos machines de développement locales qui ont VS 2013 installée.

Nous avons finalement déterminé le problème.

Lors de la création d'une nouvelle API Web MVC 4 et du choix du framework 4.0 lors de la création du projet, nous avons trouvé que la version correcte du package NuGet pour DLL était insérée dans: .. \ packages \ Microsoft.Net.Http.2.0.20710.0 \ lib \ net40 \ System.Net.Http.dll

Cependant, le fichier .csproj de ce projet indique que le chemin d'accès à ce fichier system.net.http.dll est: .. \ packages \ Microsoft.Net.Http.2.0.30506.0 \ lib \ net40 \ System.Net.Http.dll

Ainsi, lorsque la construction est tentée, elle échoue sur cette différence de chemin, mais trouve la version de framework correcte du fichier ailleurs sur la machine du développeur mais pas sur notre serveur de build TeamCity.

Jusqu'à présent, c'est la seule différence que nous avons trouvée. Changer le chemin dans le fichier .csproj et construire sur une machine de développement locale avec VS2013 fonctionne toujours.

Vérifier cela dans le contrôle de version et avoir notre serveur de build TeamCity (sans VS 2013 installé localement) trouve maintenant la version correcte du .dll dans son dossier de package NuGet pour la solution et construit avec succès plutôt que de rechercher une autre version de system.net.http .dll et trouver une version plus récente qui ne correspond pas au framework, provoquant ainsi des échecs de compilation.

Je ne sais pas si cela aide.

Vérifiez le chemin du fichier de votre projet pour la DLL et assurez-vous qu'il correspond au chemin du dossier de package pour la DLL.

Simplement simplifier les autres réponses pour ce qui a fonctionné pour moi.

Je suis allé au gestionnaire NuGet, désinstallé les packages associés (dans mon cas, «Bibliothèques clientes Microsoft ASP.NET Web API 2.1» et «Json.NET») et les ai réinstallés. Juste pris quelques clics.

Fermez le projet, ouvrez-le à nouveau. Ensuite, nettoyez Solution + Build. Travaille pour moi

Pour la version 2.2.15.0, j'ai fait ceci:

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

J'ai eu exactement le même problème! J'ai jeté un coup d'œil à mon onglet Avertissements dans VS et j'ai remarqué que l'un de mes packages nuget faisait référence INDIRECTEMENT .NETFramework Version 4.5.0.0. J'ai dû désinstaller ce package, puis réinstaller la version 4.0, mais assurez-vous de spécifier les versions de package qui prennent en charge 4.0 (il reviendra par défaut à 4.5 je crois que si vous ne spécifiez pas lors de l'installation du package). J'espère que cela t'aides!

Nous avons eu cela sur un serveur après le déploiement. Elle a été causée soit par:

A) Les anciens fichiers du dossier bin qui traînent toujours et qui auraient dû être supprimés

ou

B) Ne pas avoir accès en lecture au dossier pour l'utilisateur Identité du pool d'applications.

En d'autres termes, pour nous, cela a été résolu en fixant les autorisations sur les dossiers du site et en effaçant le dossier bin et en le redéployant.

J'ai eu le même problème avec la version 31 de Gembox.spreadsheet.dll.

"Impossible de charger le fichier ou l'assembly 'GemBox.Spreadsheet, Version = 39.3.30.1095, Culture = neutral, PublicKeyToken = b1b72c69714d4847' ou l'une de ses dépendances. La définition de manifeste de l'assembly localisé ne correspond pas à la référence d'assembly. (Exception de HRESULT: 0x80131040 ) "

J'ai essayé presque tout de ces articles et aucun d'entre eux n'a fonctionné. Il vient d'être corrigé avec une simple étape.

J'ai essayé de créer des projets individuels qui configuraient essentiellement la référence de version correcte de la dll et l'erreur avait entièrement disparu de la solution.

Allez un problème similaire et la directive mentionnée dans de nombreux commentaires a bien fonctionné

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

Cependant, vous devez vous assurer que la couverture de l'ancienne version est suffisamment élevée, sinon les versions plus récentes peuvent ne pas être redirigées vers la version spécifique dont vous avez besoin et l'emplacement utilisant cette référence plus récente ne fonctionnera pas correctement car l'ancienne référence est déjà dans le répertoire bin.

Pour cette erreur (et similaire), il vaut la peine de passer par NuGet Consolidate (Solution> Gérer les packages NuGet ...) pour vous assurer que les mêmes versions de composant référencées sont cohérentes dans chaque bibliothèque de classes référencée dans la solution, car même une version légèrement plus ancienne peut avoir des dépendances sur d'autres composants plus anciens. Il est simple à utiliser avec les mises à jour et peut vous faire gagner beaucoup de temps.

Cela a résolu ce problème pour moi et je dirais qu'il est indispensable de se familiariser avec si vous créez des bibliothèques d'assistance qui font également référence à MVC ou à d'autres composants NuGet basés sur le Web.