Erreur "Le fichier de métadonnées"… \ Release \ project.dll "est introuvable 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 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 :(

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.

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.

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.

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 .

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.

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

Rouvrez Visual Studio en tant qu'administrateur.

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.

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.

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.

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.

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.

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 .

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

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.

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

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.

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

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é :)

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

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.

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.

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.

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.

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

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?

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.

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.

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.

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.