Le fichier de métadonnées '.dll' est introuvable.

Question

Je travaille sur un projet WPF, C# 3.0, et j'obtiens cette erreur :

Error 1 Metadata file
'WORK=- \Tools\VersionManagementSystem\BusinessLogicLayer\bin\Debug
\BusinessLogicLayer.dll' could not be found C:\-=WORK=- \Tools
\VersionManagementSystem\VersionManagementSystem\CSC VersionManagementSystem

C'est ainsi que je référence mes contrôles d'utilisateur :

xmlns:vms="clr-namespace:VersionManagementSystem"
<vms:SignOffProjectListing Margin="5"/>

Cela se produit après chaque échec de la compilation. La seule façon d'obtenir la compilation de la solution est de commenter tous mes contrôles utilisateur et de recompiler le projet, puis de décommenter les contrôles utilisateur et tout va bien.

J'ai vérifié les ordres de construction et les configurations des dépendances.

Comme vous pouvez le voir, il semble avoir tronqué le chemin absolu du fichier DLL... J'ai lu qu'il y avait un bug avec la longueur. Est-ce un problème possible ?

C'est très ennuyeux et le fait de devoir commenter, construire et décommenter la construction devient extrêmement fatigant.

Answer 1

Dans mon cas, le problème a été causé par une simple erreur de construction,

erreur CS0067 : L'événement 'XYZ' n'est jamais utilisé.

qui, pour une raison quelconque, n'est pas apparu dans la fenêtre d'erreur.

À cause de cela, le système de construction de Visual Studio a semblé manquer l'erreur et a essayé de construire des projets dépendants, qui ont à leur tour échoué avec le message ennuyeux des métadonnées.

La recommandation est - aussi stupide qu'elle puisse paraître - :

Regardez d'abord votre Fenêtre de sortie !

Il m'a fallu une demi-heure avant que cette idée ne me frappe...

Answer 2

J'ai obtenu la même erreur "Metadata file '.dll' could not be found", et j'ai essayé plusieurs choses décrites ci-dessus, mais la raison de l'erreur était que je faisais référence à un fichier DLL tiers qui ciblait une version de .NET supérieure à la version de .NET cible de mon projet. La solution était donc de changer le framework cible de mon projet.

Answer 3

J'ai ajouté un nouveau projet à ma solution et j'ai commencé à obtenir ceci.

La raison ? Le projet que j'ai apporté visait un cadre .NET différent (4.6 et mes deux autres étaient 4.5.2).

Answer 4

Il semble que ce type d'erreurs soit lié au fait que Visual Studio ne fournit pas d'informations correctes sur une erreur. Le développeur ne comprend même pas la raison de l'échec de la construction. Il peut s'agir d'une erreur de syntaxe ou d'autre chose. En général, pour résoudre ce genre de problème, il faut trouver la racine du problème (par exemple, regarder le journal de construction).

Dans mon cas, le problème était en fait que la Error List n'a pas montré d'erreurs. Mais en réalité, il y avait des erreurs de syntaxe ; j'ai trouvé ces erreurs dans le fichier Output et après les avoir réparés, le problème était résolu.

Answer 5

Pour moi, il s'agissait d'essayer de trouver une DLL dans un chemin qui contenait le projet, mais nous l'avons déplacé dans un nouveau répertoire. La solution contenait le chemin d'accès correct au projet, mais Visual Studio continuait en quelque sorte à chercher dans l'ancien emplacement.

Solution : Renommez chaque projet problématique - ajoutez simplement un caractère ou autre - puis renommez-le à son nom d'origine.

Cela doit réinitialiser une sorte de cache global dans Visual Studio, car cela résout à la fois ce problème et d'autres comme celui-ci, alors que des choses comme Clean ne le font pas.