Visual Studio continue d'écraser NewtonSoft.Json.DLL avec une ancienne version
Visual Studio remplace la version correcte de NewtonSoft.Json.DLL que j'ai configurée à la fois dans mes références de projet et dans le fichier de package NuGet avec une version plus ancienne lorsque je crée un autre projet en plus du site Web qui contient la référence.
D'ACCORD. Voici le scénario:
J'ai une solution avec un service backend et un site web. Le site Web fonctionne sur .NET 4.5 et est configuré avec NuGet pour extraire la version 6.0.1 de Newtonsoft.Json.DLL.
<package id="Newtonsoft.Json" version="6.0.1" targetFramework="net45" />
Ce qui ajoute la liaison dependenAssembly au fichier web.config.
<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>
Je peux créer et exécuter ce site Web sans aucun problème.
J'ai récemment mis à jour toutes les bibliothèques de classes et le service backend de .NET 4.0 à .NET 4.5. Après la mise à jour, chaque fois que je crée l'une des bibliothèques de classes ou que j'exécute/débogue le service principal, le site Web devient inutilisable.
Could not load file or Assembly 'Newtonsoft.Json' or one of its dependencies. The located Assembly's manifest definition does not match the Assembly reference. (Exception from HRESULT: 0x80131040)
J'ai découvert cela au fait que lors de la reconstruction d'une des bibliothèques de classes ou de l'exécution/du débogage du service backend à partir de Visual Studio, le Newtonsoft.Json.DLL est remplacé par une ancienne version du fichier - la version 4.5.11. En raison de la liaison explicitement dépendante de l'assembly, chaque fois que j'accède au site Web après cela, j'obtiens l'erreur "Impossible de charger ..." mentionnée ci-dessus.
Ce serait OK si je voulais juste exécuter l'un ou l'autre du service backend ou du site Web, mais je dois les exécuter ensemble pour que mon application fonctionne correctement. Mais à cause de cette erreur, je ne peux pas faire fonctionner le service backend en même temps que le site Web ou que le site Web plante.
Comment empêcher Visual Studio d'écraser la DLL?
Notez que je n'ai la référence définie que pour 6.0.1 sur l'ensemble de la solution (c'est-à-dire qu'il n'y a pas de référence n'importe où à 4.5.11). Et sur le site Web, "Copier local" est défini sur true et "Specific Version" est également défini sur true pour le Newtonsoft.Json.DLL.
Il s'agit d'un bogue conn dans Windows Azure VS Tools
Solutions de contournement:
Supprimez le fichier Newtonsoft.Json.dll du dossier Program Files\Microsoft SDKs\Windows Azure.NET SDK\v2.3\ref \.
Désinstaller Windows Azure VS Tools v 2.3
Le problème
Votre csproj contient une référence avec un chemin non valide vers la DLL Newtonsoft.Json. Dans mon cas, c'était
<HintPath>..\..\packages\Newtonsoft.Json\lib\net45\Newtonsoft.Json.dll</HintPath>
au lieu de celui que NuGet aurait dû définir, packages\Newtonsoft.Json.8.0.3\... (y compris le numéro de version).
Étant donné que VS ne peut pas trouver la DLL, il recherchera simplement sur votre système et utilisera la première qu'il trouve. Sur mon système, c'était Azure SDK 2.9, puis Azure SDK 2.8, puis VS12/Blend/....
La solution
Certaines des solutions ci-dessus (suppression de tous les Newtonsoft.Json.dll que vous trouvez dans votre système) peuvent masquer le problème à court terme, mais la seule correction du csproj pour pointer vers le chemin correct fourni par NuGet résoudra vraiment le problème.
Autrement dit, assurez-vous que le HintPath dans votre csproj correspond au chemin du package où le package NuGet est installé.
Si vous avez bash, vous pouvez utiliser
$ grep -r HintPath * | grep Newtonsoft
dans le répertoire racine de votre solution pour trouver le csproj incriminé.
Erreurs liées
Si vous rencontrez ce problème, le démarrage de votre site Asp.Net avec la redirection explicite dans web.config peut échouer avec une page d'exception, avec le texte suivant dans le message d'erreur:
JOURNAL: Tentative de téléchargement de la nouvelle URL newtonsoft json
WRN: la comparaison du nom de l'assembly a entraîné la non-concordance: version majeure
Même si certains projets ont une référence au NuGet de Newtonsoft.Json 8.x, VS sera heureux de compiler, puis écrasera cela DLL avec l'ancien qu'il a trouvé sur le système, et échouera à Durée.
Voici la situation que j'ai eue.
3 projets en solution. Les projets A et B ont référencé Newtonsoft.Json.DLL 6.0.3 et une référence de solution au projet C. Le projet C n'a aucune référence explicite à Newtonsoft.Json.DLL.
Lors de la construction de la solution, il crée C, puis A et B - en supprimant les DLL correctes dans le bac. Mais lorsque je construis uniquement C VS supprime l'ancienne version de dll en A et B. Comme aucune référence explicite ou liaison de redirection n'existe, il le prend de GAC. De plus, la construction de A uniquement supprime les anciennes DLL en B, car il construit C au début, supprime la mauvaise version en A et B, puis construit A en mettant la bonne version.
Voici la solution - ajoutez explicitement Newtonsoft.Json.DLL 6.0.3 au projet C
Nous avons récemment rencontré le même problème. Notre solution compilerait et disposerait des DLL correctes sur nos machines de développement, mais sur notre agent de build, la mauvaise version de Newtonsoft.Json serait supprimée dans les dossiers de sortie.
Après beaucoup de temps investi, nous avons découvert que cela avait été déclenché par quelqu'un installant une version plus récente du SDK Azure sur notre agent de build que nous n'en avions localement: 2.9 au lieu de 2.5.1.
La solution de contournement que nous avons découverte consistait à inclure le package Newtonsoft.Json NuGet dans le projet every dans la solution, même si le projet n'avait pas besoin de la référence.
J'ai exactement le même problème et j'ai découvert que dans C:\Program Files\Microsoft SDKs\Windows Azure.NET SDK\v2.3\ref, j'ai Newtonsoft.Json.dll avec la même date et heure exacte que celle qui a été copié dans le dossier de mon site Web.
Après avoir renommé/supprimé le fichier Newtonsoft.Json.dll dans C:\Program Files\Microsoft SDKs\Windows Azure.NET SDK\v2.3\ref, Visual Studio cessait de remplacer ma version référencée et le site Web recommençait à fonctionner.
Mon scénario était presque exactement le même, sauf que mon Newtonsoft.JSON DLL a été copié à partir d'un emplacement différent. J'ai vérifié que ma solution faisait référence au bon fichier et à la bonne version mais lors de l'exécution, VS l'a copiée à partir d'un autre emplacement ( Vérifiez d'abord cela en faisant glisser BIN DLL dans VS ou dans les propriétés.
En fin de compte, après les avoir essayés un par un en utilisant Journaux de fusion je me suis efforcé de remplacer toutes les références de Newtonsoft.JSON.dll qui ont la même version incorrecte des fichiers programme:
- 'C:\Program Files (x86)\Microsoft SDKs\Microsoft Azure\Mobile Services\1.0'
- 'C:\Program Files\Fichiers communs\Microsoft Shared\Visual Studio\12.0'
- 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\Blend'
- etc.
Astuce rapide: dans l'Explorateur sous la vue détaillée, ajoutez 'Version du produit' comme colonne et triez-la: 
Cela ressemble toujours à un merde IDE si je définit Version spécifique pour cet assembly et le chemin du fichier est vers le correct DLL (défini par NuGet), il ne devrait vraiment pas aller le remplacer par celui d'un autre emplacement global de partage. Tout commentaire pour modifier le comportement de génération de Visual Studio ici sera apprécié car je ne le fais vraiment pas voulez faire ce type de piratage manuel sur chaque machine de développeur.
J'ai rencontré ce même type de problème aujourd'hui. J'ai découvert qu'après la construction d'une bibliothèque de classes, tous les fichiers * .dll du répertoire de sortie de cette bibliothèque de classes sont copiés dans le dossier bin de tout projet Web qui a une référence de projet à cette bibliothèque de classes. Cela peut entraîner le remplacement des assemblys compatibles par des assemblages incompatibles. Cependant, cette dll xcopy ne se produira pas pendant le déchargement du projet Web (cliquez avec le bouton droit sur le projet et choisissez "Décharger le projet").
J'ai le même problème, après avoir testé toutes les solutions, je continue à obtenir des erreurs. Il semble que cette erreur puisse se produire pour plusieurs causes.
Dans mon cas, j'utilise VS 2015, le problème était une référence inutilisée à un autre projet dans mon application qui utilise une ancienne version de newtonSoft. J'élimine la référence et la DLL n'a plus été modifiée.