Comment puis-je résoudre les conflits de version d'assembly avec JSON.NET après la mise à jour des références de package NuGet dans un nouveau projet ASP.NET MVC 5?

89

J'ai créé un nouveau projet Web ASP.NET MVC 5 dans VS 2013 (mise à jour 1), puis mis à jour tous les packages NuGet. Lorsque je construis le projet, j'obtiens l'avertissement suivant:

avertissement MSB3243: aucun moyen de résoudre le conflit entre "Newtonsoft.Json, Version = 6.0.0.0, Culture = neutre, PublicKeyToken = 30ad4fe6b2a6aeed" et "Newtonsoft.Json, Version = 4.5.0.0, Culture = neutre, PublicKeyToken = 30ad4fe6b2a6aeed".

Lorsque je vérifie le web.config, cependant, je vois qu'une redirection de liaison est en place:

  <dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0"/>
  </dependentAssembly>

C'est exactement ce que conseille l'avertissement.

Comment puis-je corriger cet avertissement?

asp.net-mvc  json.net  nuget  visual-studio-2013  asp.net-mvc-5.1 
— Jim Lamb
source
Oui, j'ai fait une reconstruction complète. J'ai également mis à jour NuGet vers la dernière version, créé une nouvelle solution et reproduit exactement le même problème.
— Jim Lamb

Réponses:

106

Voici les étapes que j'ai utilisées pour corriger l'avertissement:

  • Décharger le projet dans VS
  • Modifier le fichier .csproj
  • Rechercher toutes les références à l'assemblage Newtonsoft.Json
    • Trouvé deux, un à v6 et un à v5
    • Remplacez la référence à la v5 par la v6
  • Recharger le projet
  • Générer et signaler l'échec de la référence d'assemblage
  • Affichez les références et voyez qu'il y en a maintenant deux pour Newtonsoft.Json. Supprimez celui qui ne parvient pas à résoudre.
  • Reconstruire - pas d'avertissement
— Jim Lamb
source
12
J'ai trouvé deux références, une pour la v6 et une pour la v5 mais j'ai supprimé (non remplacé) celle de la v5. Après cela, je n'ai pas eu de problèmes comme "échec de référence d'assemblage" ou deux références à Newtonsoft.Json dans l'interface utilisateur. Je suppose que quelqu'un est bourréinstall.ps1
— ta.speot.est le
Merci pour la solution. J'ai aussi supprimé l'ancienne référence du fichier de projet et je n'ai eu aucun problème.
— Charles Prakash Dasari
31
+1 - Ça me rend vraiment fou quand je dois faire des trucs comme ça. C'est pourquoi j'hésite toujours à cliquer sur la mise à jour sur le gestionnaire de paquets nuget.
— hylander0
1
J'avais ce problème et je l'ai résolu en supprimant la référence supplémentaire dont je ne savais pas qu'elle était là. C'est le lien vers le bogue Microsoft Connect qui est à l'origine de la référence supplémentaire: connect.microsoft.com/VisualStudio/feedback/details/816725/… .
— Martin Costello
1
Dans mon cas, il y avait des références à deux versions différentes de Newtonsoft.Json 11.0.1 et 11.0.2, bien qu'il se plaignait de la version 6.0.
— Daniel Lobo
31

J'ai eu ce problème parce que j'ai mis à jour des packages, qui comprenaient Microsoft.AspNet.WebApi qui a une référence à Newtonsoft.Json 4.5.6 et j'avais déjà la version 6 installée. Ce n'était pas assez intelligent pour utiliser la version 6.

Pour le résoudre, après la mise à jour de WebApi, j'ai ouvert les outils> NuGet Package Manager> Pacakge Manager Console et exécuté:

 Update-Package Newtonsoft.Json

Le journal a montré que les versions 6.0.x et 4.5.6 étaient toutes mises à jour vers la dernière version et que tout allait bien.

J'ai le sentiment que cela reviendra.

— McGaz
source
1
J'avais le problème de plusieurs versions différentes dans ma solution qui contient plusieurs projets, cela a totalement résolu cela et mis à jour le tout vers le dernier JSON.net. Agréable!
— c0d3p03t
1
C'était la solution la plus simple et la plus directe qui a résolu mon problème. Merci!
— youngrrrr
21

J'ai trouvé de supprimer cette section du fichier de projet pour résoudre le problème.

<ItemGroup>
<Reference Include="Newtonsoft.Json">
  <HintPath>..\packages\Newtonsoft.Json.6.0.1\lib\net45\Newtonsoft.Json.dll</HintPath>
</Reference>

— szmulder
source
Ça y est. Je suppose qu'aucun de Newtonsoft.Json.6.0.1 / 6.0.3 / 6.0.5 ne correspond à la redirection de liaison '' oldVersion = "0.0.0.0-6.0.0.0" '' Mais je ne sais pas comment écrire le bon
— fantastory
C'était aussi mon problème, je ne sais pas ce qui l'a ajouté.
— amnesia
A travaillé pour moi. Erreur liée au conflit entre v6.0 et v12.0. La référence au groupe d'articles était la version 11.0. Donc pas sûr de ce qui se passe, mais la suppression du groupe d'éléments semble l'avoir résolu, au même titre que la suppression de l'erreur de compilation.
— Brian.S
13

Si aucune des solutions ci-dessus ne fonctionne, essayez de l'utiliser dans web.config ou app.config:

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
            <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30AD4FE6B2A6AEED" culture="neutral"/>
            <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0"/>
        </dependentAssembly>
    </assemblyBinding>
</runtime>
— ZeroDotNet
source
Cela convient mieux à la situation où vous avez un projet existant utilisant la version supérieure et que vous ajoutez une dépendance qui utilise une ancienne version du même package, vous redirigez donc l'ancienne version vers la nouvelle.
— Ismail Hawayel le
13

Je suis passé de Newtonsoft.Json 11.0.1 à 12.0.2. En ouvrant le fichier de projet dans Notepad ++, j'ai découvert les deux

<Reference Include="Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, processorArchitecture=MSIL">
      <HintPath>..\packages\Newtonsoft.Json.12.0.2\lib\net45\Newtonsoft.Json.dll</HintPath>
    </Reference>

et

<ItemGroup>
    <Reference Include="Newtonsoft.Json">
      <HintPath>..\packages\Newtonsoft.Json.11.0.1\lib\net45\Newtonsoft.Json.dll</HintPath>
    </Reference>
  </ItemGroup>

J'ai supprimé le ItemGroup enveloppant la référence avec le chemin d'indication vers la version 11.0.1.

Ces problèmes peuvent être extrêmement frustrants à trouver. De plus, les développeurs suivent souvent les mêmes étapes que les configurations de projet précédentes. Les configurations précédentes n'ont pas rencontré le problème. Pour une raison quelconque, le fichier de projet est parfois mis à jour de manière incorrecte.

Je souhaite désespérément que Microsoft corrige ces problèmes d'enfer de DLL de Visual Studio. Cela arrive trop souvent et stoppe la progression jusqu'à ce qu'elle soit corrigée, souvent par essais et erreurs.

— Jeremy Ray Brown
source
1
C'était exactement le problème. Merci!
— George Fabish
8

La solution finale à vos erreurs de redirection d'assemblage

D'accord, j'espère que cela devrait aider à résoudre les écarts de référence d'assemblage (sains) ...

  1. Vérifiez l'erreur.

Surfez sur le site

  1. Vérifiez web.config après la redirection d'assembly. Créez-en un s'il n'existe pas.

Redirection d'assembly web.config existante

  1. Cliquez avec le bouton droit sur la référence de l'assemblage et choisissez Propriétés.

Assemblage dans la liste de référence, dans le projet concerné

  1. Vérifiez la version (et non la version d'exécution) dans le tableau Propriétés. Bien reçu.

Tableau des propriétés montrant la version de l'assemblage

  1. Collez dans l'attribut newVersion.

Redirection d'assembly web.config avec newVersion mise à jour

  1. Pour plus de commodité, changez la dernière partie de l'ancienne version en quelque chose de haut, de rond et d'imaginaire.

Redirection d'assembly web.config avec oldVersion mise à jour

Réjouir.

Cette réponse m'a fait gagner beaucoup de temps! J'avais une application Web qui utilisait une bibliothèque C # personnalisée, les deux utilisaient le même package nuget mais l'application Web a une version plus ancienne que la bibliothèque et la redirection n'incluait pas la version utilisée par la bibliothèque.
— War Gravy
4

N'oubliez pas qu'avec la redirection de liaison

oldVersion = "0.0.0.0-6.0.0.0"

Vous dites que les anciennes versions de la DLL sont entre la version 0.0.0.0 et la version 6.0.0.0.

— Sherlock-jr
source
1
oldVersionest un peu inapproprié ici en fait, ce que vous dites, c'est que votre assembly / exe a été construit avec une référence à une version de la gamme 0.0.0.0-6.0.0.0et que la version réellement installée (et préférée) est la valeur sous newVersion(l'ancienne version serait mieux formulée comme "version attendue" et la nouvelle version seraient mieux formulées comme "version réelle disponible")
— rien n'est nécessaire
2

Personne n'a mentionné ce qui suit, ce qui, à mon avis, est la bonne solution:

Accédez au csproj du projet où le nuget est installé et définissez le AutoGEneratedBindingRedirectssur false.

<AutoGenerateBindingRedirects>false</AutoGenerateBindingRedirects>

Article complet dans MSDN.

— Veverke
source
1

J'ai mis à jour mon package et je l'ai même réinstallé - mais j'obtenais toujours exactement la même erreur que l'OP mentionné. J'ai modifié manuellement la DLL référencée en procédant comme suit.

J'ai supprimé le newtonsoft.json.dll de ma référence, puis supprimé manuellement le .dll du bin directoy. Ensuite, j'ai copié manuellement le newtonsoft.json.dll du dossier du package nuget dans le bac du projet, puis j'ai ajouté la référence en accédant au fichier .dll.

Maintenant, mon projet se reconstruit.

— Adam Heeg
source
0

J'ai eu un problème similaire et je voulais juste publier une réponse pour les autres dans ma situation.

J'ai une solution exécutant une application Web ASP.NET avec plusieurs autres projets de bibliothèque de classe C #.

Mon application Web ASP.NET n'utilisait pas json, mais d'autres projets où.

Voici comment je l'ai corrigé:

  1. Je me suis assuré que tous les projets utilisaient la dernière version (6) en utilisant NuGet Update sur tous les projets utilisant actuellement une version de json - cela n'a pas résolu le problème
  2. J'ai ajouté json à l'application Web à l'aide de NuGet - cela a résolu le problème (laissez-moi vous expliquer pourquoi):

L'étape 2 consistait tout d'abord à ajouter des informations de configuration pour json, qui suggèrent que tous les projets utilisent la dernière version (6) quelle que soit la version dont ils disposent. L'ajout de la liaison d'assembly à Web.Config est probablement le correctif.

Cependant, l'étape 2 a également nettoyé un certain code hérité. Il s'est avéré que nous avions précédemment utilisé une ancienne version (5) de json dans notre application Web et que les dossiers NuGet n'étaient pas supprimés lorsque la référence était (je suppose: manuellement) supprimée. Ajout du dernier json (6), suppression des anciens dossiers (json v5). Cela pourrait également faire partie du correctif.

— Nick Niebling
source
0

Veverke a mentionné qu'il est possible de désactiver la génération de redirections de liaison en définissant AutoGEneratedBindingRedirects sur false. Je ne sais pas si c'est une nouveauté depuis que cette question a été publiée, mais il existe une option "Ignorer l'application des redirections de liaison" dans Outils / Options / Nuget Packet Manager, qui peut être basculée. Par défaut, il est désactivé, ce qui signifie que les redirections seront appliquées. Cependant, si vous faites cela, vous devrez gérer manuellement les redirections de liaison nécessaires.

— Svein Terje Gaup
source
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.