Erreur CS1705: "qui a une version plus élevée que l'assembly référencé"

109

J'examine cela depuis un peu maintenant et je ne l'ai pas résolu. Je reçois le message d'erreur suivant:

Compiler Error Message: CS1705: Assembly 'My.Model, Version=1.1.4422.23773, Culture=neutral, 
PublicKeyToken=bfde95ba233094b2' uses 
'Common, Version=3.3.4273.24368, Culture=neutral, PublicKeyToken=bfde95ba233094b2' 
which has a higher version than referenced assembly
'Common, Version=3.3.4269.17112, Culture=neutral, PublicKeyToken=bfde95ba233094b2'

c:\WINDOWS\assembly\GAC_MSIL\Common\3.3.4269.17112__bfde95ba233094b2\Common.dll: 
(Location of symbol related to previous error)

Le serveur Web exécute le serveur 2003. Je suis allé à c: \ windows \ assembly et ai en fait remarqué qu'il y avait 3 versions de Common.dll répertoriées. La version la plus élevée répertoriée était la 3.3.4269.17112.

J'ai copié la dll avec la version: 3.3.4273.24368 dans le répertoire d'assemblage. J'ai ensuite recompilé et redéployé mon code (probablement exagéré mais bon). Lorsque j'ai ouvert mon navigateur dans une nouvelle session et que je suis retourné à l'URL du site, j'ai toujours le même message.

Je peux utiliser l'explorateur Windows et vérifier que Common.dll avec une version plus élevée est maintenant répertorié.

Que puis-je examiner de plus pour résoudre ce problème? Je ne souhaite pas modifier la référence de mon assemblage pour qu'elle pointe vers l'ancienne version.

.net web-deployment jbizzle
la source
2
*.*Numéros de version fous . Reconstruisez tout, seul moyen d'être sûr.
Hans Passant

Réponses:

68

J'ai eu cette erreur parce que "Rebuild" ne reconstruisait pas vraiment.

Solution: fermez Visual Studio, supprimez vraiment le dossier bin, puis reconstruisez, cela pourrait mieux fonctionner.

En outre, parfois Visual Studio ment sur les références, vérifiez donc le HintPathdans vos .csprojfichiers.

Nicolas Raoul
la source
2
Celui-ci a sauvé mon bacon. Courir en local était bien, mais j'ai publié un changement et les choses sont devenues farfelues. La suppression du contenu du dossier bin en ligne a forcé les choses à se synchroniser. Merci!
pStan
40

Si vous utilisez NuGet, il vaut la peine d'aller à `` Gérer les packages NuGet pour la solution '' , de trouver le package qui cause des problèmes et de lancer la mise à jour. Il devrait ensuite amener tous les packages à la dernière version et résoudre le problème.

Vaut le détour car c'est rapide et facile.

CountZero
la source
2
Cela a résolu le problème pour moi, merci. Ma situation était cependant légèrement différente: elle n'était pas répertoriée dans les mises à jour, je devais donc aller à installer et il y avait une fenêtre qui montrait la version du package par projet. J'étais en train de mettre à niveau certains anciens modules vers une nouvelle version d'un cms, donc j'ai dû accéder aux packages de problèmes, les sélectionner et cliquer sur installer. Cela aurait pu être dû au fait que le cms venait de changer pour utiliser nuget mais vous m'avez évité beaucoup de csprojretouches fastidieuses !
rtpHarry
3
Assurez-vous de mettre à jour les packages NuGet au niveau de la solution plutôt qu'au niveau du projet.
Jess
2
Cela devrait certainement être la réponse acceptée par tous les moyens, je ne l'ai pas lu mais j'ai essayé ma solution sans le vouloir, ce qui a fonctionné comme un charme.
baymax
30

Mon problème était que j'avais 2 projets référençant 2 copies différentes de la même DLL qui avait des versions différentes. Je l'ai corrigé en les supprimant tous les deux et en m'assurant qu'ils faisaient référence au même fichier dll.

Andrew Ngo
la source
13

Une cause possible est que le deuxième assembly est installé dans GAC tandis que le premier assembly, avec un numéro de version plus élevé, est ajouté aux références du projet. Pour vérifier cela, double-cliquez sur l'assemblage dans les références du projet et vérifiez s'il existe un autre assemblage portant le même nom dans l'Explorateur d'objets.

Si tel est le cas, utilisez l'utilitaire gacutil.exe pour désinstaller le deuxième assembly du GAC. Par exemple, s'il s'agit d'assemblys 64 bits:

C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\x64\gacutil.exe -u <assembly_name>
jgong
la source
Deux ans plus tard et votre suggestion a fonctionné comme un charme. L'affichage des références dans l'Explorateur d'objets l'a trié.
ceebreenk
3

Accédez à Référence et ajoutez une nouvelle référence de votre fichier dll qui est à l'origine du problème et assurez-vous que toutes vos dll sont compilées avec la même version. Cela fonctionne pour moi, j'espère que cela fonctionne pour vous aussi.

Rahul
la source
2

Mon équipe vient de rencontrer ce problème dans notre environnement de construction. Le problème était dû à une différence dans l'élément <HintPath> du fichier .csproj.

Notre assembly commun avait un chemin relatif correct vers le répertoire contenant nos assemblys de référence. L'assembly dépendant avait un chemin à partir d'une ancienne structure de répertoires. La solution a été compilée avec succès sur les machines de développement car le GAC a résolu la référence de la personne à charge à la version correcte installée dans C: \ Program Files. L'environnement de construction avait une installation héritée de l'assembly (même s'il n'aurait dû en avoir aucune) à laquelle il est retourné et donc l'erreur. La mise à jour de <HintPath> dans un éditeur de texte a corrigé le problème.

Russell Speight
la source
2

Le problème est vu si les packages nuget varient dans plusieurs projets au sein de la solution.

Vous pouvez résoudre ce problème en mettant à jour les packages nuget vers une version commune avec tous les PROJETS de la SOLUTION

Krishna Prasad S
la source
1

Eu un problème similaire. Mon problème était que j'avais plusieurs projets dans la même solution qui référençaient chacun une version spécifique d'une DLL mais des versions différentes. La solution consistait à définir «Version spécifique» sur false dans toutes les propriétés de toutes les références.

gnuchu
la source
1

Je sais que cela a été demandé il y a un certain temps, après avoir essayé certaines des étapes ci-dessus. Ce qui m'a aidé, ce sont les étapes suivantes et cet article .

J'ai localisé la référence et changé le PublicKeyToken de celui référencé à l'ancien.

J'espère que cela aide aussi.

Harry
la source
1

J'ai eu la même erreur. J'ai corrigé l'erreur après l'installation Microsoft.AspNetCore.ALLdans le projet de test.

Haktan Enes Biçer
la source
0

Dossier de collection de dll main
Si vous solution a un dossier de poubelle pour les fichiers dll de différentes bibliothèques
lib, source, libs, etc.
Vous pouvez obtenir ce trouble si vous ouvrez votre solution (pour un temps de sapins) dans Visual Studio. Et le dossier de collecte de votre dll est manqué d'une manière ou d'une autre ou un fichier dll concret est manqué.

Visual Studio essaiera silencieusement de remplacer la référence de dll par quelque chose de lui-même. Si VS réussit, une nouvelle référence sera persistante pour votre solution locale. Pas pour les autres clones / checkouts.

Ie votre <HintPath>sera ignoré et votre fichier de projet (.csproj) ne sera pas modifié.
Comme exemple de moi

<Reference Include="DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>..\..\..\lib\DocumentFormat.OpenXml.dll</HintPath>
</Reference>

Le DocumentFormat.OpenXmlsera référencé à partir de C:\Program Files (x86)\Open XML SDK\V2.5\libpas d'un solution\..\libdossier.

Solution de contournement rapide

  • vérifier et restaurer le dossier de collecte de votre dll
  • à partir de l'Explorateur de solutions, faites Décharger le projet , puis Recharger le projet .

La bonne solution de contournement consiste à migrer vers le gestionnaire de packages NuGet.

it3xl
la source
0

pour SharePoint, assurez-vous que sous votre dossier racine, vous n'avez pas de dossier "bin" avec vos DLL, si c'est le cas, supprimez-le. (et changez "Copier Local" en faux dans VS).

développeur
la source
0

Les références d'un projet de site Web sont stockées dans son fichier web.config. Mettez à jour la référence pour corriger l'erreur.

J'ai passé du temps à regarder toutes les références de ma solution avant de me rendre compte que j'avais oublié les références dans le fichier web.config.


la source
0

J'ai eu le même problème avec UnitTestingProject, où dans le MainProject j'utilisais "System.Web.Mvc, Version = 3.0.0.0" et dans UnitTestingProject j'utilisais "System.Web.Mvc, Version = 3.0.0.1"

Modifiez ce qui suit dans le <Reference Include="System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"> <HintPath>..\packages\Microsoft.AspNet.Mvc.3.0.50813.1\lib\net40\System.Web.Mvc.dll</HintPath> </Reference>

Buminda
la source
0

J'ai obtenu ceci après avoir ajouté Episerver Find à notre site et installé le package NuGet correspondant pour Episerver Find.

Le correctif était simple: mettre à jour également tous les modules complémentaires liés à Episerver (même s'ils ne semblent pas liés: CMS, CMS.TinyMCE, CMS.UI, etc.)

Après avoir mis à jour tous les modules complémentaires Episerver possibles et recompilé, l'erreur a disparu.

webDevAndEverythingElse
la source
0

Dans mon scénario, j'ai modifié le fichier .csproj pour mon application dotnetCore. J'ai remarqué que la balise TargetFramework avait une valeur de netcoreapp2.1 et la balise RuntimeFrameworkVersion une valeur de 2.0.0 . J'ai donc changé la RuntimeFrameworkVersion en 2.1.0 , enregistré, redémarré VS et reconstruit, puis résolu les erreurs.

J'espère que ceci vous aidera ...

Bonne chance,

Sugeshan

Sugeshan Govindsamy
la source
-1

Dans votre projet, recherchez des références System.Web.Mvc vérifiez la version.

Après cela, faites un clic droit sur références -> assemblys et recherchez system.web.mvc et configurez- le.

Le problème provoque les différentes versions de ces assemblys .

Modifier: sélectionnez ensuite gérer les packages NuGet et installer les mises à jour (si vous avez plusieurs projets, installez également les mises à jour.)

La mise à jour importante est Microsoft.AspNet.Mvc et Microsoft.Net.Compilers ne l'oubliez pas!

Hadnazzar
la source
-1

Dans notre équipe, nous travaillions sur différents ordinateurs avec git. Quelqu'un a mis à jour un dllet je ne l'ai pas eu. Je viens de mettre à jour mes références de dépendances et le problème est résolu.

Masoud Darvishian
la source
-3

J'ai eu un problème similaire, j'avais créé une DLL, c'est-à-dire A.dll, qui faisait référence à d'autres DLL, c'est-à-dire B.dll.

J'ai créé une application C.exe et référencé les DLL A.dll et B.dll.

Solution - En supprimant la référence de B.dll de c.exe, j'ai pu résoudre le problème.

J'espère que cela t'aides.

Yahya
la source