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 bizarre.
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 = neutre, PublicKeyToken = 31bf3856ad364e35' ou l'une de ses dépendances. La définition du manifeste de l'Assemblée localisée ne correspond pas à la référence de l'Assemblée. (Exception de HRESULT: 0x80131040)
Description: une exception non gérée s'est produite lors de l'exécution de la demande Web en cours. Consultez 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 paquets 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 comprends pas très bien d'où provient la référence 2.0.0.0 et pourquoi cela fonctionnerait localement, mais pas sur le serveur.
En regardant les dépendances de 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 ça 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 repose toujours sur WebForms. Donc, quelque chose se gâte. Mais si je nettoie sous la section Assembly de la page web.config, l’application ne se trouve même plus.
J'ai eu le même problème avec le déploiement de mon application sur appharbor. Le problème, il ne supporte pas encore .NET 4.5. Ce que j'ai fait.
- Basculé mon projet sur le profil .NET 4.0.
- Paquet NuGet d'API Web désinstallé.
- Installez à nouveau le package NuGet de l'API Web (Bêta).
- Vérifié que le fichier .csproj contient pour TOUS les assemblys référencés, il sera donc toujours extrait du dossier Bin au lieu de GAC.
La même erreur s'est produite 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 web.configruntimeque j'ai trouvée
<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é pour
<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>
Maintenant, fonctionne comme un charme.
Le mien a travaillé avec:
Notez la redirection de 1-4 à 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 mon cas, je l'ai corrigé beaucoup plus facilement, il suffit de donner un chemin 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 le dossier Références de votre projet, il devrait y avoir une référence à cette dll et la version devrait être 2.0.0.0. Assurez-vous qu'il est défini sur Copy Local = true. Et assurez-vous ensuite qu'il se trouve dans le dossier bin de votre application serveur.
C’est l’une des bibliothèques gérées par nuget. Alors ouvrez Nuget et assurez-vous que tout est à jour. Et dans votre répertoire de packages de 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-là.
Simplement simplifier les autres réponses pour ce qui a fonctionné pour moi.
Je suis allé dans le gestionnaire NuGet, j'ai désinstallé les packages associés ("Bibliothèques clientes Microsoft ASP.NET Web API 2.1" et "Json.NET" dans mon cas) et les ai réinstallés. Juste pris quelques clics.
Je faisais face à ce problème sur un serveur de test (Windows 2008 R2) qui était censé être "prêt" pour le déploiement;)
L'idée é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.
Fixé en utilisant les étapes ci-dessous:
Téléchargé du programme d’installation autonome .NET Framework 4.5 de ICI
Ran le programme d'installation sur la machine de déploiement
Après l'installation du framework, le serveur voulait un redémarrage, et volla! Nous sommes prêts à partir !!
Dans la configuration de fichier, j'ai supprimé l'Assemblée dépendante:
<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 cela fonctionne bien.
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 paquets NuGet (car d'autres paquets semblaient en dépendre). Cependant, ces paquets 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ésinstallez BCL Portability Pack dans NuGet Package Manager
- Éliminer manuellement les bibliothèques dépendantes (System.Net.Http. *, Version 2.1.10.0)
- Ajouter une référence à System.Net.Http 2.0.0.0
Nous utilisons VS 2013, nous avons créé une nouvelle API Web MVC 4 et nous avons eu un problème avec le fichier system.net.http.dll qui n’était pas la version correcte lorsqu’il est construit sur notre serveur TeamCity, mais cela fonctionne bien sur nos machines de développement locales dotées de 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 de l'infrastructure 4.0 lors de la création du projet, nous avons trouvé la version correcte du package NuGet pour DLL insérée dans: .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, cette différence de chemin échoue, mais elle trouve la version de structure correcte du fichier ailleurs sur la machine du développeur, mais pas sur notre serveur de génération 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 la machine de développement locale avec VS2013 fonctionne toujours.
En vérifiant cela dans le contrôle de version et en ayant notre serveur de génération TeamCity (sans VS 2013 installé localement), la version correcte du fichier .dll est maintenant trouvée dans le dossier du package NuGet pour la solution et est générée avec succès plutôt que de chercher une autre version de system.net.http .dll et trouver une version plus récente qui ne correspond pas au framework, ce qui provoque des échecs de construction.
Pas sûr que cela aide.
Vérifiez le chemin d'accès au fichier de votre projet pour DLL et assurez-vous qu'il correspond au chemin d'accès au dossier du package pour la DLL.
J'ai eu le même problème avec Gembox.spreadsheet.dll version 31.
"Impossible de charger le fichier ou l'assembly 'GemBox.Spreadsheet, Version = 39.3.30.1095, Culture = neutre, PublicKeyToken = b1b72c69714d4847' ou l'une de ses dépendances. La définition du manifeste de l'assembly situé. Assembly Reference. (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 construire des projets individuels qui définissaient la référence de version correcte à la DLL et l'erreur était totalement résolue.
Pour cette erreur (et similaire), il vaut la peine de passer par NuGet Consolidate (Solution> Gérer les paquets NuGet ...) pour s'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 en conjonction avec les mises à jour et peut vous épargner beaucoup de peine.
Cela a résolu le 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.
J'ai eu exactement ce même problème! J'ai jeté un coup d'œil à l'onglet Avertissements dans VS et constaté qu'un de mes paquets de nugets faisait référence INDIRECTEMENT à .NETFramework version 4.5.0.0. Je devais désinstaller ce paquet, puis réinstaller la version 4.0, mais assurez-vous de spécifier les versions de paquet qui prennent en charge la version 4.0 (le retour à la version 4.5 reviendra par défaut à 4.5 si vous ne spécifiez pas lors de l'installation du paquet). J'espère que cela t'aides!
Cela s'est produit sur un serveur après le déploiement. Cela a été causé par:
A) Les anciens fichiers du dossier bin qui traînaient et qui auraient dû être supprimés
ou
B) N'ayant pas d'accès en lecture au dossier pour l'utilisateur d'identité du pool d'applications.
En d'autres termes, cela a été résolu pour nous en fixant les autorisations sur les dossiers du site, en effaçant le dossier bin et en le redéployant.
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>
Aller 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>
Bien que vous deviez vous assurer que la couverture de l'ancienne version est suffisamment élevée, sinon les versions les plus récentes risquent de ne pas être redirigées vers la version dont vous avez besoin et l'emplacement utilisant cette nouvelle référence ne fonctionnera pas correctement car l'ancienne référence est déjà dans le répertoire bin.
Fermez le projet, ouvrez-le à nouveau. Ensuite, Nettoyez Solution + Build. Travaille pour moi