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

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.

3 idées à essayer:

1. Assurez-vous que toutes vos dll sont compilées avec la même version de Common.
2. Vérifiez que vous avez des références de projet dans votre solution au lieu de références de fichier.
3. Utilisez des redirections de liaison dans votre web.config. ( Version initialement liée à Wayback Machine )

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.

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.

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.

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>

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.

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.

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

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.

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.

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

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.

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).

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.

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>

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.

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

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!

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.

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.