Erreur CS1705 : "qui a une version supérieure à l'assemblage référencé".

Question

Je me suis penché sur la question depuis un certain temps déjà et je n'ai pas réussi à la résoudre. 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 fonctionne sous Server 2003. Je suis allé à c : \windows\assembly et j'ai remarqué qu'il y avait 3 versions de Common.dll. La version la plus élevée était 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 trop, mais bon). Lorsque j'ai ouvert mon navigateur dans une nouvelle session et que je suis retourné à l'URL du site, j'ai obtenu le même message.

Je peux utiliser l'explorateur Windows et vérifier que la version supérieure de Common.dll est maintenant listée aussi.

Que puis-je faire de plus pour résoudre ce problème ? Je ne veux pas changer la référence dans mon assemblage pour pointer vers l'ancienne version.

Answer 1

J'ai supprimé les dossiers bin et obj manuellement, reconstruit, et ça a marché.

Answer 2

Quelque chose de similaire m'est arrivé sur Visual Studio 2019 après avoir mis à jour certains paquets NuGet d'Entity Framework. Peut-être que quelqu'un pourrait tomber sur ce problème lié à Entity Framework ou à un autre paquet NuGet.

Dans mon cas, une dépendance de projet faisait référence à une version plus élevée d'un paquet Nuget que le projet dépendant (qui contient la référence).

Pour une raison quelconque, sur le .csproj le fichier PackageReference entrée pour Microsoft.EntityFrameworkCore.Tools a inclus l'étiquette PrivateAssets . Cela signifie, en regardant la documentation :

Ces actifs seront consommés mais ne seront pas transférés au projet parent.

Le comportement souhaité dans mon cas est que le projet parent inclue le projet dépendant et également ses dépendances, car cela réduit la duplication des paquets NuGet entre les projets liés.

Par conséquent, la modification de la .csproj du projet enfant :

<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="5.0.11">
  <PrivateAssets>all</PrivateAssets>
  <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
</PackageReference>

A :

<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="5.0.11" />

Et la reconstruction a résolu le problème.

Answer 3

J'ai eu un problème similaire. J'avais plusieurs projets dans la même solution qui faisaient chacun référence à une version spécifique d'une DLL, mais à des versions différentes. La solution consistait à mettre la valeur "Specific Version" à false dans toutes les propriétés de toutes les références.

Answer 4

Je sais que cette question a été posée 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 qui est référencé à l'ancien.

J'espère que cela vous aidera aussi.

Answer 5

Dossier de collection de la dll Handmade
Si votre solution a un dossier de déchets pour les fichiers dll de différentes bibliothèques.
lib , source , libs etc.
Vous pouvez rencontrer ce problème si vous ouvrez votre solution (pour la première fois) dans Visual Studio. Et le dossier de collecte de votre dll est manquant pour une raison ou une autre ou un fichier dll concret est manquant.

Visual Studio essaiera silencieusement de substituer la référence de la dll par quelque chose qui lui est propre. Si VS réussit, une nouvelle référence sera persistante pour votre solution locale. Pas pour les autres clones/checkouts.

C'est-à-dire que votre <HintPath> sera ignorée 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>

El DocumentFormat.OpenXml sera référencé à partir de C:\Program Files (x86)\Open XML SDK\V2.5\lib pas d'un solution\..\lib dossier.

Solution rapide

• vérifiez et restaurez votre dossier de collecte de dll
• à partir de Solution Explorer, faire Décharger le projet entonces Projet de rechargement .

bonne solution de contournement est de migrer vers le gestionnaire de paquets NuGet.