Impossible de charger le fichier ou l’assembly System.Net.Http.Primitives. La définition de manifeste de l’assembly localisé ne correspond pas à la référence de l’assembly

Je travaille sur un programme qui utilise l’API Google. Cependant, chaque fois que je lance mon programme, l’erreur suivante persiste:

Impossible de charger le fichier ou l’assembly ‘System.Net.Http.Primitives, Version = 1.5.0.0, Culture = neutral, PublicKeyToken = b03f5f711d50a3a’ ou l’une de ses dépendances. La définition de manifeste de l’assembly situé ne correspond pas à la référence de l’assembly.

J’utilise Visual Studio 2012 express. J’ai essayé de suivre ce lien et j’ai parcouru de nombreux forums, mais aucun ne semble fonctionner. Le problème principal semble provenir du fichier DLL “Google.Apis.dll” que j’ai référencé et qui fait référence à System.Net.Http.Primitives v1.5.0.0. Cependant, la version de mon programme est la version 2.2.13.0. J’ai essayé d’avoir la référence de programme v1.5.0.0 (je parviens à trouver la DLL avec le code source de Google.Apis), mais cela n’a causé qu’un autre problème dans lequel j’avais besoin d’une version plus récente de System.Net. Http.Primitives.

J’ai essayé de trouver un moyen de contourner ce problème, mais je n’arrive pas à trouver quoi que ce soit qui fonctionne. Merci pour le temps.

J’ai rencontré le même problème avec les API de Google. Le problème principal est que si vous installez les bibliothèques de clients Microsoft Http, il place dans votre projet une version mise à jour de la DLL System.Net.Http.Primitives. Web.config suppose que vous utilisez toujours la version par défaut de 1.5. Il y a deux choses à faire pour y remédier:

Tout d’abord: mise à jour vers les dernières versions de l’ API Google et des bibliothèques Microsoft Http Client . Vous pouvez installer les mises à jour via NuGet. Faites un clic droit sur votre site Web, cliquez sur “Gérer les packages NuGet”, sélectionnez Mises à jour sur la gauche. Au moment de cet article, certaines des API de Google ne sont que des versions préliminaires. Vous pouvez les installer via NuGet en sélectionnant “Inclure les versions préliminaires” en haut à gauche de l’écran de mise à jour.

Deuxième mise à jour / append un dépendant dans votre web.config. Pour ce faire, vous devez connaître la version de System.Net.HTTP.Primitives.dll installée. Recherchez dans votre répertoire bin dans l’Explorateur Windows. Recherchez System.Net.HTTP.Primitives.dll, cliquez dessus avec le bouton droit, sélectionnez les propriétés et cliquez sur l’onglet “Détails”. Notez la version qui s’y trouve. Au moment de cet article, la mienne était 4.0.10.0 .

Puis ajoutez / mettez à jour une section dependentAssembly pour la version correcte.

        

Ce qui a fonctionné pour moi était d’installer simplement les “Microsoft Http Client Libraries” de Nuget.

Ajoutez les éléments suivants à votre fichier web.config (app.config):

         

Pour moi, cela a fonctionné comme suit:

Sur Visual Studio (2012)> Outils> Gestionnaire de packages Nuget> Console du gestionnaire de packages. En haut de la console du gestionnaire de package, j’ai la source du package: nuget.org Projet par défaut: le projet qui nécessite System.Net.Http.Primitives Regarder à l’intérieur du fichier de projet (yourproject.csproj) avec un éditeur J’ai lu quelle version est nécessaire mon cas était Microsoft.Net.Http.2.2.28)

Je suis donc allé sur https://www.nuget.org/packages/Microsoft.Net.Http/ et j’ai cliqué sur ma version sous “Historique des versions” (faites défiler un peu la page si vous ne la voyez pas). Après avoir choisi la version que vous copiez la commande suggérée – dans mon cas c’était:

Package d’installation Microsoft.Net.Http -Version 2.2.28

mais si vous avez besoin de la dernière version est juste ceci:

Package d’installation Microsoft.Net.Http

et vous le collez sur votre console Visual Studio Package Manager précédemment ouverte comme je l’ai décrit précédemment. Exécutez la commande.

Dans le projet sous les références, System.Net.Http.Primitives est maintenant mis à jour.

J’ai eu un problème similaire.

Essayez de mettre à jour nuget (outils / extensions et mises à jour …) Résolu ce problème et d’autres problèmes pour moi.

/ Jonas

Nous avions le même problème. Mais dans mon cas, la solution de modification de app.config par Paul ne fonctionnait pas. La raison en est que je l’utilise comme un plug-in dans une autre application. Donc, il considère le fichier de configuration de cette application. Nous avons donc obtenu le code Google API de GitHub et créé la bibliothèque Google.Apis.Core après avoir supprimé la dépendance de System.Net.Http.Primitives. Ensuite, nous avons utilisé cette DLL qui a résolu notre problème.

La réponse ci-dessus à propos de assemblybinding est correcte, mais vous ne devez PAS toucher la machine.config.

L’assemblybinding doit être défini dans le fichier de configuration de tous les assemblys EXECUTABLE de votre projet (.exe.config) qui font référence à votre bibliothèque, et non dans les assemblys de bibliothèque (.dll.config).

J’ai rencontré ce problème lorsque j’ai publié mon code qui utilise Google.Apis.Drive.v2 (v1.9.2.1860) pour la société pour laquelle je travaille. Je leur ai donné l’exe et toutes les DLL générées par Visual Studio (et NuGet), et elles ont eu l’erreur. Je n’ai jamais eu l’erreur.

Le correctif a été facile (une fois que je l’ai compris): lors de l’installation de l’API à partir de Nuget, le fichier ‘assemblyname.exe.config’ est automatiquement généré dans le dossier de sortie (aka Debug ou Release). Tout ce que vous avez à faire est d’inclure ce fichier lorsque vous exécutez l’assemblage à un autre endroit que celui dans lequel il a été généré. Voici le code de ce fichier pour moi:

               

Ceci est essentiellement le “second” correctif de Paul, mais il est automatiquement généré par le gestionnaire de paquets. Le problème pour moi a été lorsque j’ai essayé son “premier” correctif en mettant à jour à Google.Apis.Auth et Google.Apis.Core (v1.9.3), il a empiré les choses. J’obtiendrais la même erreur sauf que maintenant c’était pour “Google.Apis.Core” était la mauvaise version (bien que cela aurait probablement pu être résolu aussi en incluant le même fichier .exe.config.)

J’espère que cela aidera quelqu’un, je sais que ce fil est assez vieux, mais c’est celui qu’une recherche rapide sur Google m’a conduit.

Edit: oublié de mentionner, cela concerne une application de console ciblant .NET 4.5. Une partie est probablement encore pertinente pour d’autres cibles .NET ou ASP.NET mais je ne suis pas sûr. Votre kilométrage peut varier.

D’une manière ou d’une autre, la réponse populaire de Paul Lemke ne fonctionnait pas pour moi. Le projet est une application webforms qui a démarré avec .net v 2.0 et a été mise à niveau vers .net version 4.5

J’ai mis à jour les paquets et nuget a créé l’assemblage et le bindingRedirects dépendants.

Selon certains commentaires, ce n’est probablement pas la meilleure idée de changer votre fichier machine.config local.

Applyly, j’avais un atsortingbut dans mon fichier web.config qui faisait que l’application ignore les bindingRedirects.

  

J’ai supprimé cet atsortingbut xmlns et il a commencé à fonctionner.

A pu résoudre ce problème assez facilement. Il suffit d’ouvrir le gestionnaire de packages Nuget et de mettre à jour le package de la bibliothèque client Microsoft ASP.NET Web API 2.2. Cette mise à jour de Microsoft.Net.Http vers la version la plus récente a permis de résoudre le problème lié à l’assembly System.Net.Http.Primitives. J’espère que cela t’aides!

Dans mon cas, je faisais référence aux packages NuGet à partir d’une bibliothèque de classes. NuGet ne parvient pas à nous informer que app.config de la bibliothèque de classes est complètement ignoré et que nous devons copier manuellement son contenu dans le fichier app.config de .exe.

NuGet a apporté la modification suivante dans Web.Config

à

Cela faisait suite à l’installation et à la suppression ultérieure (par le retour du contrôle de version) de ce package https://www.nuget.org/packages/Microsoft.AspNet.WebApi.MessageHandlers.Compression/

J’ai rencontré un problème similaire avec les scripts PowerShell pour TFS 2017. Les scripts appelaient le code .NET pour effectuer des actions personnalisées lors des processus de génération. J’ai continué à recevoir des erreurs sur les conflits de version de DLL.

Je n’ai pas pu résoudre le problème avant d’avoir implémenté un hook dans l’événement AppDomain AssemblyResolve selon cette réponse: Rendre les redirections de liaison fonctionnent pour les compléments Office

Cette solution a forcé le processus à utiliser les DLL du chemin actuel. Je sais que c’est un peu un piratage, mais j’avais lu que lors de l’exécution de PowerShell, vous ne pouvez pas toujours utiliser les redirections de liaison, ce que je pensais à l’origine: https://github.com/google/google-api-dotnet -client / issues / 555

Dans mon cas, Nuget ajoute automatiquement les pages suivantes à web.config

                    

Mais j’ai toujours le message d’erreur ci-dessus, finalement je le trouve. Vous devez copier ces balises dans le fichier machine.config situé dans C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Config \ machine.config.

Pour trouver le tag “runtime” sur machine.config, remplacez ou ajoutez (s’il n’y en a pas) avec vos tags de votre web.config (ceux que j’ai listés ci-dessus).