Erreur “Impossible de trouver le fichier de métadonnées ‘… \ Release \ project.dll’ dans Visual Studio”

Récemment, j’ai commencé à recevoir ce message au hasard:

Le fichier de métadonnées ‘… \ Release \ project.dll’ est introuvable dans Visual Studio

J’ai une solution avec plusieurs projets. Le mode de construction actuel est Debug et toutes les configurations de projets sont définies sur Debug. Mais quand j’essaie d’exécuter le projet principal – cela me donne parfois quelques erreurs, toutes étant “Fichier de métadonnées” … \ Release \ projectX.dll “introuvable” – et regardez, il est dit à propos de RELEASE dossier, bien que le mode actuel soit Debug. Pourquoi? J’ai essayé de rechercher des références à “Release \ projectX.dll” dans tous les fichiers de solution, et j’en ai trouvé un dans le fichier ResolveAssemblyReference.cache.

J’ai fait de bonnes recherches sur Internet et j’ai trouvé quelques personnes ayant un problème similaire, mais il n’y avait pas de solution, ou du moins pas de solution opérationnelle.

J’ai essayé de supprimer les références à ces projets et de les lire, mais dans un certain temps, je recommence à recevoir ces erreurs.

Cela ressemble à un bug. Pourquoi recherche-t-il les projets référencés dans les dossiers de version lorsque j’utilise toujours le mode de débogage?

PS Pour ceux qui ont rencontré ce problème: je ne pouvais pas le résoudre facilement. Il a disparu seulement après avoir réinstallé Windows 🙁

Tout le monde a raison … essayez tout … (par ordre de temps à perdre)

  1. Avez-vous un code erroné? Fixez cela en premier.
  2. Nettoyer la solution et redémarrer Visual Studio
  3. Supprimer / Ajouter des références
  4. Vérifiez votre ordre de construction avec des projets plus importants et vérifiez
  5. Reconstruire manuellement des sous-projets
  6. Copier manuellement les DLL entre les projets dans les dossiers associés
  7. Va prendre un café, joue au flipper et reviens demain… tu penseras peut-être à autre chose en attendant.

J’ai eu exactement le même problème. Grande solution de studio visuel avec plus de 50 projets.

Toutes les références ont été ajoutées en tant que projets. L’ordre de construction du projet était correct (cliquez avec le bouton droit sur le projet et sélectionnez l’ordre de construction).

Cependant, lors de la construction de certains projets de niveau supérieur, le projet “racine” dont ils dépendaient n’a pas été construit.

Le problème était que ces projets n’étaient pas sélectionnés pour être construits sous la configuration actuelle (je ne sais pas comment cela s’est passé).

Pour vérifier cela, sélectionnez «Gestionnaire de configuration» (menu Générer). Vérifiez si les projets problématiques sont configurés pour être construits.

Lorsque vous dites que vous avez supprimé des références à ces projets et que vous les avez rajoutées, comment les avez-vous rajoutées, exactement? Avez-vous utilisé l’onglet “Parcourir” dans la boîte de dialog “Ajouter une référence” dans Visual Studio? Ou avez-vous utilisé l’onglet “Projets” (qui répertorie les projets voisins dans votre solution)?

Modifier : Si vous utilisez l’onglet “Parcourir” et ajoutez manuellement la référence à votre fichier .dll situé dans le dossier / Release, Visual Studio recherchera toujours le fichier .dll à cet emplacement, quel que soit le mode que vous utilisez. actuellement dans (Debug ou Release).

Si vous avez supprimé le fichier .dll réel du dossier Release (manuellement ou en faisant “Clean Solution”), votre référence sera interrompue car le fichier .dll n’existe pas.

Je vous suggère de supprimer la référence à ProjectX.dll et de l’append à nouveau – mais cette fois, utilisez l’onglet “Projets” de la boîte de dialog “Ajouter une référence”. Lorsque vous ajoutez une référence de cette manière, Visual Studio sait où obtenir le fichier .dll approprié. Si vous êtes en mode Débogage, il sera extrait du dossier / Debug. Si en mode de libération, le dossier / Release. Votre erreur de génération devrait disparaître et vous ne ferez plus (de manière incorrecte) référence à une version .dll en mode débogage.

Eh bien, ma réponse n’est pas seulement le résumé de toutes les solutions, mais elle offre plus que cela.

Section 1):

En solutions générales:

J’ai eu 4 erreurs de ce type (“fichier de métadonnées introuvable”) avec 1 erreur indiquant “Impossible d’ouvrir le fichier source” (“Erreur non spécifiée”) “.

J’ai essayé de me débarrasser de l’erreur «fichier de métadonnées introuvable». Pour cela, j’ai lu de nombreux articles, blogs, etc. et constaté que ces solutions pouvaient être efficaces (en les résumant ici):

  1. Redémarrez VS et essayez à nouveau de construire.

  2. Allez dans “Explorateur de solutions” . Faites un clic droit sur la solution. Aller aux propriétés . Allez dans “Gestionnaire de configuration” . Vérifiez si les cases à cocher sous “Générer” sont cochées ou non. Si certains ou tous sont décochés, alors vérifiez-les et essayez de construire à nouveau.

  3. Si la ou les solutions ci-dessus ne fonctionnent pas, suivez la séquence mentionnée à l’étape 2 ci-dessus et même si toutes les cases à cocher sont cochées, décochez-les, vérifiez à nouveau et essayez de les reconstituer.

  4. Composer les dépendances et les projets:

    Allez dans “Explorateur de solutions” . Faites un clic droit sur la solution. Allez dans “Dépendances du projet …” . Vous verrez 2 tabs: “Dépendances” et “Ordre de construction” . Cet ordre de construction est celui dans lequel la solution est créée. Vérifiez les dépendances du projet et l’ordre de construction pour vérifier si un projet (disons ‘project1’) dépendant des autres (disons ‘project2’) essaie de se construire avant celui-ci (project2). Cela pourrait être la cause de l’erreur.

  5. Vérifiez le chemin du fichier .dll manquant:

    Vérifiez le chemin d’access du fichier .dll manquant. Si le chemin contient de l’espace ou tout autre caractère de chemin non valide, supprimez-le et essayez de le reconstruire.

    Si c’est la cause, ajustez l’ordre de construction.


Section 2):

Mon cas particulier:

J’ai essayé toutes les étapes ci-dessus avec différentes permutations et combinaisons avec le redémarrage de VS peu de fois. Mais ça ne m’a pas aidé.

Donc, j’ai décidé de me débarrasser de toute autre erreur que je rencontrais (‘Le fichier source n’a pas pu être ouvert (‘ Erreur non spécifiée ‘)’).

Je suis tombé sur un blog: http://www.anujvarma.com/tfs-errorsource-file-could-not-be-opened-unspecified-error/#comment-1539

J’ai essayé les étapes mentionnées dans ce blog et je me suis débarrassé de l’erreur ‘Le fichier source ne pouvait pas être ouvert (‘ Erreur non spécifiée ‘)’ et étonnamment, je me suis débarrassé d’autres erreurs (‘fichier de métadonnées introuvable’) .


Section 3):

Morale de l’histoire:

Essayez toutes les solutions mentionnées dans la section (1) ci-dessus (et toute autre solution) pour éliminer l’erreur. Si rien ne fonctionne, selon le blog mentionné dans la section (2) ci-dessus, supprimez les entrées de tous les fichiers sources qui ne sont plus présents dans le contrôle de code source et le système de fichiers de votre fichier .csproj .


J’ai déjà eu ce problème et le seul moyen que j’ai trouvé pour le résoudre est d’exécuter Clean Solution puis de redémarrer Visual Studio.

Rouvrez Visual Studio en tant qu’administrateur.

Pour moi, le framework cible est généralement désactivé (4.5.2 au lieu de 4.6) Si vous corrigez le framework cible du projet pour qu’il corresponde au framework cible de la solution et de la build, un nouveau fichier .dll sera créé.

La plupart des réponses indiquent que vous devez supprimer les bibliothèques de votre solution, ceci est vrai, mais lorsque vous rajoutez les bibliothèques, l’erreur s’affiche à nouveau. Vous devez vérifier si toutes les bibliothèques référencées ont un framework .net compatible avec le framework .net de votre solution. Corrigez ensuite toutes les erreurs dans votre code et reconstruisez la solution.

Avez-vous vérifié les parameters du gestionnaire de configuration? Dans la boîte de dialog des parameters du projet, en haut à droite.

Il arrive parfois qu’une entrée de débogage entre entre toutes les entrées de la version. Si c’est le cas, la dépendance automatique créée par le graphique de dépendance de la solution devient confuse.

J’ai aussi vu cette erreur dans les solutions où j’ai plusieurs projets (généralement des projets NetTiers où j’ai mis à jour un ou plusieurs sous-projets pour cibler le framework 4.0). Cela peut être problématique à supprimer. Cependant, il peut souvent être résolu en corrigeant d’abord toutes les autres erreurs dans les sous-projets (par exemple, les références manquantes), en reconstruisant individuellement ces sous-projets, puis en supprimant / rajoutant toute référence à ces sous-projets dans Visual Studio. Personnellement, j’ai eu peu de chance de résoudre cette erreur en nettoyant la solution seule.

Nous avons récemment rencontré ce problème après la mise à niveau vers Office 2010 à partir d’Office 2007 – nous avons dû modifier manuellement les références de notre projet à la version 14 des Interops Office que nous utilisons dans certains projets.

J’espère que ça aide – il nous a fallu quelques jours pour le comprendre.

Dans mon cas, il a été causé par deux choses (VS.2012):

1) L’un des projets était configuré pour AnyCPU au lieu de x86

2) Un projet référencé avait en quelque sorte décoché la case à cocher “Construire”.

Ne vérifiez votre construction | Configuration Manager pour avoir un aperçu de ce qui est en cours de construction et pour quelle plate-forme. Assurez-vous également de le vérifier à la fois pour Debug & Release car ils peuvent avoir des parameters différents.

Dans mon cas, j’avais des erreurs dans mon code. Visual Studio a montré l’erreur que vous aviez au lieu des erreurs réelles, comme les erreurs de syntaxe ou les noms de classe inconnus. Essayez de nettoyer la solution et de construire un projet après projet. De cette façon, vous découvrirez les erreurs réelles.

Encore une fois, c’est exactement ce qui cause l’erreur pour moi .

J’ai eu ce problème et j’ai mis du temps à le comprendre. Le problème est apparu lorsque j’ai retiré des projets de la solution et remplacé ceux avec des packages nuget.

La solution semblait aller bien, mais le fichier .csproj contenait encore plusieurs fois ces projets en référence.

Semble que VS ne nettoie pas ce fichier de manière appropriée. Il faisait encore référence aux projets retirés sous le capot. Lorsque manuellement supprimé les références du fichier csproj tout fonctionne à nouveau! wohoo

Ce problème est dû aux fichiers pdb ou CodeContracts.

Pour le résoudre:

  1. Nettoyez votre dossier de sortie et reconstruisez la solution.

  2. Configurez à nouveau le CodeContracts ou désactivez-le pour la génération temporaire.

Nous avons ce problème assez souvent, mais uniquement avec des références aux projets C ++ / CLI des projets C #. C’est évidemment un bogue au fond de Visual Studio que Microsoft a décidé de ne pas corriger, car il est «trop complexe» et ils ont promis une refonte du système de compilation C ++ qui est maintenant ciblé pour Visual Studio 2010.

C’était il y a quelque temps, et peut-être que le correctif est allé dans Visual Studio 2008; Je n’y ai plus donné suite. Cependant, notre solution de contournement typique était

  • Configuration du commutateur
  • Redémarrez Visual Studio
  • Construire la solution

J’ai eu le même problème moi-même.

Visual Studio 2013 m’a seulement dit qu’il ne pouvait pas y faire référence et qu’il ne pouvait pas trouver les métadonnées. Lorsque j’ai ouvert ma solution (qui contient plusieurs projets), j’ai dit que j’utilisais des projets inférieurs à la version Framework d’un de mes projets.

J’ai donc tout basculé vers la version 4.5 et cela a fonctionné à nouveau.

Je me rappelle avoir eu un problème similaire il y a quelques mois. Je l’ai résolu temporairement en copiant la DLL référencée dans le dossier Release, satisfaisant ainsi les attentes de Visual Studio. Plus tard, j’ai découvert la référence à la DLL de la version dans mon code actuel. Vous devriez essayer d’effectuer une recherche dans tout le projet pour \ release \ project.dll.

En outre, j’ai remarqué que les projets de test unitaires Visual Studio placent parfois un atsortingbut “DeploymentItem” sur chacune des méthodes de test pointant vers votre DLL cible, et si vous basculez entre Debug et Release, Visual Studio peut devenir confus si la DLL n’est plus dans l’emplacement prévu. D’après mon expérience, ces atsortingbuts peuvent être supprimés en toute sécurité si vous ne les avez pas placés vous-même dans le cadre d’un scénario de «déploiement unique».

J’ai eu ce problème et c’était dû à une méthode invalide dans la bibliothèque fautive (dll) qui n’a pas renvoyé une valeur, par exemple

public bool DoSomething() { //I never bothered putting code here.... } 

Quand j’ai fait ceci, tout compilé 🙂

Parfois, VS2010 bascule ma configuration de Any CPU vers Mixed Platforms. Lorsque cela se produit, je reçois ce message d’erreur.

Pour le résoudre, je reviens à Any CPU:
1. Cliquez avec le bouton droit sur la solution et sélectionnez les propriétés.
2. Cliquez sur Propriétés de configuration, puis sur le bouton Configuration Manager ….
3. Sous Plate-forme de solution active, sélectionnez Any CPU

Je trouve que cela m’apparaît généralement lorsque j’ai encore une déclaration de méthode dans une interface, qu’une classe implémente, mais que j’avais plus tard supprimée et que j’avais oublié de la retirer également de l’interface. En général, je sauvegarde la solution complète toutes les 30 minutes, puis je reviens à une version antérieure si je ne trouve pas l’erreur.

J’ai fini par supprimer mes références (je les avais ajoutées correctement en utilisant l’onglet projets, et elles montaient très bien), en éditant mes fichiers .csproj à la main et en supprimant les entrées bizarres – et en configurant mes sorties pour le débogage et release, x86 et x64 et tout cpu à tous soit “\ bin” – je l’ai construit une fois, puis rajouté la référence (encore une fois, en utilisant l’onglet projets), et tout a recommencé à fonctionner pour moi. Je n’ai pas du tout besoin de redémarrer Visual Studio.

Pour moi, cela a été provoqué par la réécriture de la cible de compilation pour ne pas générer de dll. En supprimant cela pour revenir à la cible de génération par défaut, le problème a été résolu.

Cela semble se produire lorsque vous extrayez une solution avec plusieurs projets qui ont des références entre eux, et que vous ne l’avez pas déjà construite. Si vous avez des références directes aux DLL, au lieu de faire référence au projet, vous obtiendrez ce message. Vous devez toujours utiliser l’onglet Projets de la boîte de dialog Ajouter une référence pour append une référence à un projet dans la même solution. De cette façon, VS peut connaître le bon ordre dans lequel construire la solution

La même chose m’est arrivée aujourd’hui comme décrit par Vidar.

J’ai une erreur de génération dans une bibliothèque auxiliaire (référencée par d’autres projets) et au lieu de me signaler une erreur dans la bibliothèque d’assistance, le compilateur affiche la liste des erreurs de type MetaFile-not-found. Après avoir corrigé l’erreur de génération dans Helper Library, les erreurs MetaFile ont disparu.

Y a-t-il un paramètre dans VS pour améliorer cela?

J’ai eu le même problème. J’ai remarqué que mon contexte de firebase database (EF4) qui se trouvait dans la DLL du projet n’était pas reconnu pour une raison quelconque. Je l’ai supprimé et en ai créé un autre à la place. et ça l’a résolu pour moi.

Eu le même problème aujourd’hui.

Mon application, une application Windows Forms, avait accidentellement une référence à elle-même. Bizarre.

Une fois supprimé, l’erreur a disparu.

La référence a été ajoutée chaque fois que j’ai fait glisser un contrôle utilisateur, situé dans le projet Windows Forms lui-même, vers un formulaire.

Je suis d’accord avec la plupart des réponses affichées ici. Cependant, si toutes les solutions suggérées ne fonctionnaient pas, considérez que vous avez probablement un autre type d’erreur dans votre liste d’erreurs, à savoir empêcher la création d’une DLL de projet par les VS pour les autres projets. Peu importe l’ordre ou la configuration de la construction, vous ne pourrez pas vous débarrasser de l’erreur “métadonnées” avant que les autres problèmes ne soient résolus.

VÉRIFIEZ VOTRE CHEMIN DE PROJET. Il ne devrait pas avoir de caractère irrégulier comme la virgule et l’espace

par exemple, ce chemin est incorrect: d: \ mes applications \ Project1

et c’est vrai chemin d: \ mes_applications \ Project1

Le studio visuel ne peut pas construire le projet quand il y a un caractère non alphabétique et numérique dans son chemin dans le disque et qu’il ne montre aucun message pour cette erreur!

De plus, certains outils d’installation ont le même problème lorsqu’ils démarrent l’installation et ne peuvent pas être extraits.

J’ai eu le même problème. La suppression manuelle et l’ajout des DLL n’ont pas aidé. ClassLibraries n’a pas compilé pour tous les projets et manquait dans le dossier … \ bin \ Debug du projet [car j’ai nettoyé la solution par erreur]. La bibliothèque de classes n’ayant pas été compilée, cela signifie qu’il peut y avoir des erreurs quelque part dans l’un de ces sous-projets .

Solution: Étant donné que mes DLL étaient là pour le dossier … \ bin \ Release , j’ai essayé de reconstruire en mode Release et j’ai trouvé une erreur sur une ligne dans l’un des sous-projets. La résolution de l’erreur et la reconstruction de la solution ont permis d’éliminer l’erreur de génération.