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


92

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.


Avez-vous utilisé la fonctionnalité «Ajouter des dépendances déployables» pour ce projet?
ChristiaanV

Non, je n'ai pas essayé ça. Mais j'ai tout mis en place et maintenant ça marche ... Pas vraiment satisfaisant, mais ...
Remy

J'ai ce problème à chaque fois que je redémarre ma machine et que je relance également Visual Studio. D'une manière ou d'une autre, cela a disparu si je nettoie puis reconstruis la solution.
frostshoxx

Réponses:


30

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.

1
D'une manière ou d'une autre, mon projet a commencé à fonctionner, mais je ne sais pas pourquoi ... Votre approche semble réalisable.
Remy

alexanderb - comment puis-je passer au profil .NET 4.0. Dans Visual Studio? Où se trouve le dossier bin? Le fichier .csproj est-il le fichier web.config? Thx
WhoAmI

114

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.


4
Les assemblys doivent-ils toujours être définis pour copier localement avec cette modification?
Rasmus Christensen

3
Le problème pour moi était que l'un de mes packages Web Api NuGet contenait une dépendance sur System.Net.Http 2.0.0.0 mais ma référence que j'avais était 2.1.10.0 qui était sortie dans mon dossier bin.
JustinMichaels le

2
C'est correct (comme l'a dit Justin Michaels). La dépendance fait référence à 2.0.0.0 mais votre référence d'assembly est à 2.1.xx Tout ce dont vous avez besoin pour résoudre ce problème est la redirection de liaison.
Tod Thomson

2
Celui-ci doit être marqué comme la bonne réponse. Je suppose que c'est pourquoi tous les autres utilisateurs poussent cette option. Merci, Krzysztof!
Blaise

3
Le problème n'est probablement pas la référence directe à System.Net.Http, mais une référence indirecte qui est utilisée dans l'une des autres bibliothèques que vous référencez. C'est pourquoi la configuration de la copie locale ne résoudra généralement pas ce problème.
Paul Keister

10

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>

J'ai fait quelque chose comme ça, mais j'ai mis à jour newVersion vers 4.0.0.0 et laissé oldVersion comme 0.0.0.0-2.0.0.0
Veritoanimus

2

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.


1
En fait, c'est ce qui me trouble. J'utilise nuget et j'ai ce dossier. Mais si je regarde System.Net.Http, il a la version 1.0.0.0
Remy

1
C'est exactement comme ça que je l'ai réparé! Puisque tout a fonctionné localement. J'ai juste cliqué avec le bouton droit de la souris sur la référence et dans les propriétés, j'ai mis Copy localà vrai ce qui le résout! plus facile / mieux que de déconner dans les fichiers web.config. Ajoutez simplement la dll à votre dossier bin.
JP Hellemons

2

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

1

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

1

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.


Pour afficher correctement les balises XML, formatez votre texte sous forme de code. Pour cela, ajoutez simplement quatre espaces avant chaque ligne.
Artemix

Tnx Artemix, ceci est mon premier commentaire;)
StefanoM5

1

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


1

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.


1

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.


0

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


0

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>

0

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!


0

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.


0

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.


0

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.


0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.