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

135

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 dedans. Le mode de génération actuel est Debug et les configurations de tous les projets sont définies sur Debug. Mais quand j'essaie d'exécuter le projet principal - parfois cela me donne quelques erreurs, qui sont toutes "Le fichier de métadonnées '... \ Release \ projectX.dll' n'a pas pu être trouvé" - et, regardez, cela dit à propos de RELEASE dossier, bien que le mode actuel soit Debug. Pourquoi? J'ai essayé de rechercher une référence à "Release \ projectX.dll" dans tous les fichiers de solution, et j'en ai trouvé une dans le fichier ResolveAssemblyReference.cache.

J'ai fait une bonne recherche sur Internet et j'ai trouvé quelques personnes avec un problème similaire, mais il n'y avait pas de solution, ou du moins pas de solution fonctionnelle.

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

Cela ressemble à un bug. Pourquoi recherche-t-il les projets référencés dans les dossiers Release alors que j'utilise toujours le mode 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 :(

nightcoder
la source
La première chose à faire pour des problèmes comme celui-ci est de supprimer le fichier .suo et de le reconstruire.
évent
ce problème peut se produire si une dll référencée utilise une version différente (inférieure) de .net Framework
m4ngl3r
J'avais ce problème régulièrement jusqu'à ce que je désactive les builds parallèles. Je pense qu'il y a un bogue dans la vérification des dépendances de construction parallèle, probablement lié à la mise en cache d'informations obsolètes. (Pour mémoire, j'utilise des versions parallèles maintenant, et je viens de construire à nouveau si le problème se produit, ce qui fonctionne généralement.)
yoyo
Le double possible du fichier
Michael Freidgeim

Réponses:

138

Tout le monde a raison ... essayez tout ... (dans l'ordre d'un peu à beaucoup de temps perdu)

  1. Avez-vous un mauvais code? Corrigez 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 les sous-projets
  6. Copiez manuellement les DLL entre les projets dans les dossiers bin associés
  7. Allez prendre un café, jouez au flipper et revenez demain ... vous pourriez penser à autre chose en attendant.
beauXjames
la source
17
Vous devez nettoyer toutes les ERREURS et stabiliser les solutions / projets.
Ravi Ram
cela se produit en raison de la différence de noms dans le nom du dossier et le nom de l'espace de noms. Si vous créez un espace de noms sous un certain nom, et que vous le renommez plus tard, l'espace de noms aura l'ancien nom lui-même. Et la compilation prendra l'ancien chemin pour trouver le fichier .dllet .exe. Pour éviter cela, ouvrez le .csprojfichier de chaque espace de noms avec un fichier texte et recherchez l'ancien chemin dans le fichier. supprimez-le, nettoyez et reconstruisez la solution. Cela a fonctionné pour moi. J'ai passé une journée entière à travailler sur ce problème.
Sooraj le
Si vous n'obtenez pas de succès et que cela prend du temps, recommencez simplement à essayer certaines des choses de base. J'ai commencé à créer des sous-projets, j'ai toujours eu des erreurs, mais j'ai ensuite fermé et rouvert VS, reconstruit la solution, tout fonctionnait.
Chris Halcrow
6
J'avais des noms d'espaces de noms et de projets incompatibles dans une DLL référencée maison. En outre, il a été construit avec .NET 4.5.2 au lieu de 4.5. Homme!
Jess
1
Essayez de supprimer le fichier .suo. Il est relativement courant qu'il soit corrompu.
Timbo
21

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

Pour vérifier cela, sélectionnez "Configuration Manager" (menu Build) et vérifiez si les projets problématiques sont configurés pour être compilés.

dapim
la source
Je vous remercie! Cela a très bien fonctionné pour moi lorsque, pour une raison quelconque, ma configuration de version n'a pas généré un de mes projets.
Vectovox
Tu m'as sauvé la vie!
Chethan Shetty
16

Lorsque vous dites que vous avez supprimé des références à ces projets et les avez ré-ajoutées, comment les avez-vous rajoutées exactement? Avez-vous utilisé l'onglet «Parcourir» dans la boîte de dialogue «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 .dll qui se trouve dans le dossier / Release, Visual Studio recherchera toujours le .dll à cet emplacement, quel que soit le mode dans lequel vous vous trouvez actuellement en (Debug ou Release).

Si vous avez supprimé le fichier .dll réel du dossier Release (manuellement ou en effectuant «Nettoyer la solution»), votre référence sera interrompue car le .dll n'existe pas.

Je suggère de supprimer la référence à ProjectX.dll, et de l'ajouter à nouveau - mais cette fois, utilisez l'onglet "Projets" dans la boîte de dialogue "Ajouter une référence". Lorsque vous ajoutez une référence de cette façon, Visual Studio sait où obtenir le fichier .dll approprié. Si vous êtes en mode Débogage, il l'obtiendra dans le dossier / Debug. En mode Release, le dossier / Release. Votre erreur de génération devrait disparaître et vous ne ferez plus (incorrectement) référence à une version .dll en mode débogage.

Darren Steinweg
la source
J'ai utilisé l'onglet "Parcourir" dans la boîte de dialogue "Ajouter une référence"
nightcoder
1
Pour moi, Visual Studio avait créé un projectname.v11 de type "Visual Studio Solution User Options". J'ai supprimé ce fichier et redémarré et tout allait bien.
Wes Grant
15

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

Section 1):

Dans les solutions générales:

J'ai eu 4 erreurs de ce type («le fichier de métadonnées n'a pas pu être trouvé») avec 1 erreur disant «Le fichier source n'a pas pu être ouvert (« 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 j'ai trouvé que ces solutions pouvaient être efficaces (en les résumant ici):

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

  2. Accédez à «Explorateur de solutions» . Faites un clic droit sur Solution. Allez dans Propriétés . Allez dans 'Configuration Manager' . Vérifiez si les cases à cocher sous «Construire» sont cochées ou non. Si certains d'entre eux ou tous ne sont pas cochés, vérifiez-les et réessayez de construire.

  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 à nouveau de construire.

  4. Ordre de construction et dépendances du projet:

    Accédez à «Explorateur de solutions» . Faites un clic droit sur Solution. Allez dans «Dépendances du projet ...» . Vous verrez 2 onglets: «Dépendances» et «Ordre de construction» . Cet ordre de génération est celui dans lequel la solution est générée. Vérifiez les dépendances du projet et l'ordre de construction pour vérifier si un projet (disons 'project1') qui dépend d'autres (disons 'project2') essaie de construire avant celui-là (project2). Cela pourrait être la cause de l'erreur.

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

    Vérifiez le chemin du fichier .dll manquant. Si le chemin contient un espace ou tout autre caractère de chemin non valide, supprimez-le et réessayez de construire.

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


Section 2):

Mon cas particulier:

J'ai essayé toutes les étapes ci-dessus avec diverses permutations et combinaisons avec le redémarrage de VS à quelques reprises. Mais cela ne m'a pas aidé.

J'ai donc décidé de me débarrasser d'une 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 n'a pas pu être ouvert (`` Erreur non spécifiée '') '' et, étonnamment, je me suis débarrassé d'autres erreurs (`` Le fichier de métadonnées n'a pas pu être trouvé '') .


Section 3):

Morale de l'histoire:

Essayez toutes les solutions mentionnées dans la section (1) ci-dessus (et toutes les autres solutions) 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 source qui ne sont plus présents dans le contrôle de source et le système de fichiers de votre fichier .csproj .


Vikram
la source
1
Votez cette réponse parce que nous rencontrions ce problème pour un collègue. Son système a perdu la plupart / toutes ses dépendances, donc lors de la construction, il ne serait pas construit dans le bon ordre, car le "fichier de métadonnées pour" n'importe quel.dll "n'existe pas". Nous venons de parcourir tous ses projets avec un autre système pour valider toutes les dépendances dont il avait besoin pour chaque projet.
jmbertucci
Bien ... Je suis heureux que ma réponse vous ait aidé.
Vikram
11

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.

Jasonh
la source
1
Cela n'aide pas dans ma situation, après peu de temps, le problème réapparaît.
nightcoder le
C'est ce qui m'a résolu.
splintor
3
Celui-ci a également fonctionné pour moi. A fait plusieurs nettoyages et rien n'a fonctionné. Une fois que j'ai fait un nettoyage et redémarré, il a recommencé à fonctionner. Comme c'est ennuyeux.
Ricky
8

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

Adam Weitzman
la source
J'ai eu le même problème pour un projet créé avec une ancienne version de Visual Studio. Après la mise à jour de VS, des projets ont été créés avec une version plus récente de .NET et ont provoqué le problème DLL introuvable. (Accédez au volet des propriétés du projet pour afficher / modifier la version .NET.) Merci!
Tony S Yu
Merci des millions de fois (c'est le nombre d'autres solutions que j'ai essayées). Cela a fonctionné. Pour une raison quelconque, la bibliothèque que
j'ajoute
1
J'ai ajouté un nouveau projet de bibliothèque de classes (dll) qui a été référencé dans plusieurs autres projets. La nouvelle DLL était .NET Framework 4.8 tandis que tous les autres projets étaient 4.7.2. Changer le cadre cible (dans les propriétés du projet) en 4.7.2 a corrigé ce problème pour moi. Merci Adam!
iCode
7

Rouvrez Visual Studio en tant qu'administrateur.

Sebastian Patten
la source
3

La plupart des réponses indiquent que vous devez supprimer les bibliothèques de votre solution, c'est vrai, mais lorsque vous ajoutez à nouveau 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. Puis corrigez toutes les erreurs dans votre code et reconstruisez la solution.

Oscar Canek
la source
3

Avez-vous vérifié les paramètres du gestionnaire de configuration? Dans le coin supérieur droit de la boîte de dialogue des paramètres du projet.

Parfois, il arrive qu'entre toutes les entrées de version, une entrée de débogage entre. Si tel est le cas, la dépendance automatique créée par le graphe de dépendances de la solution devient complètement confuse.

Totonga
la source
Je l'ai vérifié. Tous les projets ont la même configuration.
nightcoder
2

J'ai également 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 cadre 4.0). Cela peut être problématique à supprimer. Souvent, cela peut être résolu, cependant, en corrigeant d'abord toutes les autres erreurs dans les sous-projets (par exemple, toutes les références manquantes), en reconstruisant individuellement ces sous-projets, puis en supprimant / en rajoutant toutes les références à ces sous-projets dans Visual Studio. Personnellement, j'ai eu peu de chance de résoudre cette erreur en nettoyant seule la solution.

Shaun3180
la source
1
La suppression des références d'autres projets (mes projets d'interface utilisateur et de test, par exemple), la correction des erreurs (dans le projet Core), la création, puis la réajout de ces références ont fait l'affaire pour moi.
Ken Pespisa
2

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 vers la version 14 d'Office Interops que nous utilisons dans certains projets.

J'espère que cela aide - il nous a fallu quelques jours pour le comprendre.

Anthony Collins
la source
2

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

1) Un des projets a été configuré pour AnyCPU au lieu de x86

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

Vérifiez votre Build | Configuration Manager pour avoir une vue d'ensemble de ce qui est en cours de création et pour quelle plateforme. Assurez-vous également de le vérifier pour le débogage et la version car ils peuvent avoir des paramètres différents.

Seigneur des scripts
la source
2

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

Encore une fois, c'est justement ce qui cause l'erreur pour moi .

bytecode77
la source
2

J'ai eu ce problème et j'ai mis du temps à le résoudre. Un problème est survenu lorsque j'ai supprimé des projets de la solution et les ai remplacés par des packages nuget.

La solution semblait convenir, mais le fichier .csproj contenait toujours ces projets plusieurs fois comme référence.

Il semble que VS ne nettoie pas ce fichier correctement. Il faisait toujours référence aux projets supprimés sous le capot. Lorsque vous supprimez manuellement les références du fichier csproj, tout fonctionne à nouveau! wohoo

Elfe du Tarmo
la source
2

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

Pour le résoudre:

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

  2. Reconfigurez le CodeContracts ou désactivez-le pour la génération temporaire.

user1889439
la source
2

Nous avons ce problème assez souvent, mais uniquement avec des références à des projets C ++ / CLI à partir de 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 construction C ++ qui est désormais ciblé pour Visual Studio 2010.

C'était il y a quelque temps, et peut-être que le correctif est même entré dans Visual Studio 2008; Je n'ai plus suivi ça. Cependant, notre solution de contournement typique était

  • Configuration du commutateur
  • Redémarrez Visual Studio
  • Construisez la solution
Mémoire insuffisante
la source
Après que ce problème disparaisse pour toujours ou juste temporairement? Et qu'entendez-vous par «configuration du commutateur»? Par exemple, j'utilise toujours la configuration de débogage. Que devrais-je faire?
nightcoder
Il disparaît temporairement. En fait, cela peut ne pas être une solution pour vous si vous ne changez jamais de configuration entre le débogage et la publication. Ou passer à la version puis au débogage pourrait le résoudre, qui sait;)
OutOfMemory
Eh bien, il y a quelques jours, je suis passé à la version Release, j'ai créé la solution, puis je suis revenu à Debug. Après cela, le problème a muté :): maintenant je n'obtiens qu'une seule erreur de ce type au lieu de quelques-unes - c'est comme si d'autres projets avaient été "corrigés" :)
nightcoder
2

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), cela m'a dit que j'utilisais des projets inférieurs à la version cadre de l'un de mes projets.

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

Jamie
la source
C'était la même résolution que j'ai trouvée en rencontrant ce problème. Certaines des références utilisaient un Framework supérieur à mon application de base, lorsque j'ai changé le Framework de l'application de base en 4.5.2 (le même que les autres références), le problème a disparu. Cependant, VS n'a rien dit sur les différentes versions de framework.
NoLifeKing
1

Il me semble me souvenir d'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 Release dans mon code actuel. Vous devriez essayer d'effectuer une recherche dans l'ensemble du projet pour \ release \ project.dll.

En outre, j'ai remarqué que les projets de test unitaire de Visual Studio mettent parfois un attribut «DeploymentItem» sur chacune des méthodes de test pointant vers votre DLL cible, et si vous basculez entre Debug et Release, Visual Studio peut être confus si la DLL n'est plus à l'emplacement prévu. D'après mon expérience, ces attributs 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».

Robert Harvey
la source
1

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

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

}

Quand j'ai fait cela, tout était compilé :)

Vidar
la source
J'allais écrire cette même réponse mais j'ai remarqué que vous aviez déjà mentionné ce problème. J'ai eu le même problème, où je n'ai pas retourné de valeur booléenne et le message d'erreur pour ce problème a été caché parmi des tonnes d'autres problèmes générés après coup.
gonzobrains
1

Parfois, VS2010 bascule ma configuration de n'importe quel processeur vers des plates-formes mixtes. Lorsque cela se produit, j'obtiens ce message d'erreur.

Pour le résoudre, je repasse sur N'importe quel processeur:
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 N'importe quel processeur

Gars
la source
1

Je trouve que cela me vient généralement à l'esprit lorsque j'ai encore une déclaration de méthode dans une interface, qu'une classe implémente, mais que j'avais supprimée plus tard et j'avais oublié de la supprimer également de l'interface. En général, je sauvegarde simplement la solution entière toutes les 30 minutes, puis je reviens à une version antérieure si je ne trouve pas l'erreur.

Hans Rudel
la source
1

J'ai fini par supprimer mes références (je les avais ajoutées correctement en utilisant l'onglet projets, et elles construisaient très bien), éditant à la main mes fichiers .csproj et supprimant les entrées bizarres qui n'appartenaient pas - et définissant mes sorties pour le débogage et release, x86 et x64 et tous les processeurs doivent tous être "\ bin" - Je l'ai construit une fois, puis re-ajouté la référence (encore une fois, en utilisant l'onglet projets), et tout a recommencé à fonctionner pour moi. N'a pas du tout besoin de redémarrer Visual Studio.

BrainSlugs83
la source
1

Pour moi, cela était dû au fait que la cible Build avait été réécrite pour ne pas afficher la dll. La suppression de cela pour revenir à la cible de build par défaut a résolu le problème.

Jim Jeffries
la source
1

dans mon cas, je travaillais sur un maître de branche. J'ai donc vérifié la branche principale, exécuté une construction, puis vérifié ma branche. Cela a résolu le problème. Si vous êtes déjà sur master, je vous suggère de vérifier le commit précédent, puis de le construire.

jayasurya_j
la source
1
Hou la la! J'ai essayé tellement d'options, rien n'a fonctionné. Mais cela a résolu le problème! Thanks mate :)
Tharindu
0

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 encore créée. Si vous avez des références directement aux dll, au lieu de référencer le projet, vous recevrez ce message. Vous devez toujours utiliser l'onglet Projets de la boîte de dialogue Ajouter une référence pour ajouter une référence à un projet dans la même solution. De cette façon, VS peut connaître le bon ordre dans lequel créer la solution

Juancentro
la source
0

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

J'ai une erreur de construction dans une bibliothèque d'assistance (qui est référencée par d'autres projets) et au lieu de me dire qu'il y a une erreur dans la bibliothèque d'assistance, le compilateur propose une liste d'erreurs de type MetaFile-not-found. Après avoir corrigé l'erreur de construction dans Helper Library, les erreurs MetaFile ont disparu.

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

Santoo
la source
0

J'ai eu le même problème. J'ai remarqué que mon contexte de base de données (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 cela l'a résolu pour moi.

mashta gidi
la source
0

J'ai 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ée, l'erreur a disparu.

La référence était ajoutée chaque fois que je faisais glisser un contrôle utilisateur, situé dans le projet Windows Forms lui-même, vers un formulaire.

Christophe Geers
la source
0

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

Solution: comme 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 éliminé l'erreur de construction.

shaz
la source
0

Pour moi, Visual Studio avait créé un projectname.v11 de type "Visual Studio Solution User Options". J'ai supprimé ce fichier et redémarré et tout allait bien.

Wes Grant
la source