Message d'erreur “fichier de Métadonnées '...\Release\project.dll " ne peut pas être trouvé dans Visual Studio”

J'ai eu exactement le même problème. Grande solution visual studio avec+ de 50 projets.

Toutes les références ont été ajoutées sous forme de projets.
Projet d'ordre de construction est correcte (clic droit sur votre projet et sélectionnez ordre de construction).

Cependant lors de la construction de certains des plus hauts niveau des projets de la "racine" du projet qu'ils dépendent n'ont pas été construits.

Le problème est que ces projets n'ont pas été retenus pour la construction dans la configuration actuelle (je ne sais pas comment c'est arrivé).

Pour vérifier cela, sélectionnez "Gestionnaire de Configuration" (menu de construction) e vérifiez si la problématique projets sont mis à construire.

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

Section (1):

En général des solutions:

J'ai eu 4 erreurs de ce type (les métadonnées de fichier n'a pas pu être trouvée") avec 1 erreur de dire " Source de Fichier Ne Peut Être Ouvert ("erreur non spécifiée")'.

J'ai essayé de se débarrasser de métadonnées de fichier n'a pas pu être trouvé d'erreur". Pour cela, j'ai lu de nombreux messages, les blogs, etc et a trouvé ces solutions peuvent être efficaces (les résumer ici):

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

2. Aller à "Solution Explorer". Clic droit sur la Solution. Aller à Propriétés. Aller à "Gestionnaire de Configuration". Vérifier si les cases à cocher sous 'Construire' sont vérifiées ou non. Si tout ou partie d'entre eux ne sont pas cochées, puis de les vérifier et essayer de construction à nouveau.

3. Si la solution ci-dessus(s) ne fonctionne pas, puis suivez la séquence mentionnée dans l'étape 2 ci-dessus, et même si toutes les cases sont cochées, les décocher, vérifier à nouveau et essayez de construire à nouveau.

4. Ordre de construction et les Dépendances d'un Projet:

   Aller à "Solution Explorer". Clic droit sur la Solution. Aller à 'les Dépendances d'un Projet...'. Vous verrez 2 onglets: 'Dépendances' et "Build Order",. Cet ordre de construction est celui dans lequel la solution s'appuie. Vérifiez les dépendances d'un projet et de le construire afin de vérifier si certaines de projet (dire "projet1"), qui dépend des autres (dire "project2') est d'essayer de construire avant que l'un (project2). Cela peut être la cause de l'erreur.

5. Vérifiez le chemin d'accès à la disparition de l' .dll:

   Vérifiez le chemin d'accès à la disparition de l' .dll. Si le chemin d'accès contient des espaces ou tout autre chemin d'accès non valide caractère, retirez-le et essayez de construire à nouveau.

   Si c'est la cause, puis de régler l'ordre de la génération.

   ---

Section (2):

Mon cas particulier:

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

Donc, j'ai décidé de me débarrasser d'une autre erreur, j'ai été à venir à travers les ('Fichier Source ne Peut Pas Ê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ébarrasser de l'erreur 'Fichier Source ne Peut Pas Être Ouvert ("erreur non spécifiée") ' et étonnamment je me suis débarrassé d'autres erreurs (les métadonnées de fichier n'a pas pu être trouvée") ainsi.

---

Section (3):

Morale de l'histoire:

Essayer toutes les solutions comme le mentionne le paragraphe (1) ci-dessus (et d'autres solutions) pour se débarrasser de l'erreur. Si rien ne fonctionne sur le blog mentionné dans la section (2) ci-dessus, supprimer les entrées de tous les fichiers sources qui ne sont plus présents dans le contrôle de source et le système de fichiers à partir de votre .fichier csproj.

---

Ré-ouvrez Visual Studio en tant qu'Administrateur.

La plupart des answares dire que vous devez supprimer les bibliothèques de votre solution, c'est vrai, mais lorsque vous ajoutez de nouveau les bibliothèques de l'erreur sera affiché à nouveau. Vous devez vérifier si toutes les bibliothèques référencées compatible .net framework avec le .net framework de votre solution. Puis fixer toutes les erreurs dans votre code et de reconstruire la solution.

J'ai aussi vu cette erreur dans les solutions où j'ai plusieurs projets (généralement netTiers projets où j'ai mis à jour un ou plusieurs des sous-projets afin de cibler le framework 4.0). Il peut être difficile à enlever. Souvent, il peut être résolu, cependant, par la fixation de toutes les autres erreurs dans les sous-projets (par exemple, toutes les références manquantes), individuellement reconstruction de ces sous-projets, puis à enlever/rajouter toutes les références à ces sous-projets dans Visual Studio. Personnellement, j'ai eu peu de chance, la résolution de cette erreur par la solution de nettoyage seul.

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

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

2) Un projet qui a été référencé avait en quelque sorte la "construction" de la case décochée.

Faire vérifier votre Build | Gestionnaire de Configuration pour obtenir une vue d'ensemble de ce qui est en cours de construction et pour la plate-forme. Aussi assurez-vous de vérifier à la fois Debug & Libération, car ils peuvent avoir des paramètres différents.

J'ai eu ce problème et a pris du temps à le comprendre. Problème est venu quand j'ai enlevé les projets de la solution et a remplacé ceux avec les packages nuget.

Solution semble être bien mais la .csproj fichier contenait toujours les projets à plusieurs reprises à titre de référence.

Semble que VS ne permet pas de nettoyer ce fichier de façon appropriée. C'était encore le référencement supprimés projets sous le capot. Quand supprimé manuellement les références de fichier csproj tout fonctionne à nouveau! wohoo

Nous avons ce problème assez souvent, mais seulement avec des références à C++/CLI projets de projets C#. C'est évidemment un bug au plus profond de Visual Studio et Microsoft a décidé de ne pas corriger, parce que c'est "trop complexe" et ils ont promis une refonte de la génération C++ système qui est désormais ciblée pour Visual Studio; 2010.

C'était il y a quelques temps, et peut-être le correctif est même allé dans Visual Studio; 2008; je n'ai pas suivi sur plus. Cependant, généralement, notre solution a été

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

Me semble me rappeler avoir un problème similaire il y a quelques mois. Je l'ai résolu temporairement par la copie de référence de la DLL dans le dossier de Version, ainsi satisfaire Visual Studio attentes. Plus tard, j'ai découvert la référence à la Version de la DLL dans mon code. Vous devriez essayer de faire une recherche par le biais de l'ensemble du projet pour \release\project.dll.

Aussi, j'ai remarqué que Visual Studio test de l'unité des projets parfois mettre un "DeploymentItem" attribut sur chacune des méthodes d'essai pointant vers votre cible de DLL, et si vous basculez entre Debug et Release, Visual Studio peuvent se confondre si la DLL n'est plus dans l'emplacement prévu. Dans mon expérience, ces attributs peuvent être supprimés en toute sécurité si vous n'avez pas les mettre là-même dans le cadre d'un déploiement unique" scénario.

Parfois VS2010 commutateurs de ma configuration à partir de n'Importe quel CPU pour des plates-formes Mixtes. Quand cela arrive, je reçois ce message d'erreur.

De le résoudre de revenir à n'Importe quel CPU:

1. Clic droit sur la solution et sélectionnez propriétés.

2. Cliquez sur Propriétés de Configuration puis de la Configuration du Gestionnaire de bouton.

3. En vertu de l'Actif de la solution de plate-forme de sélectionner n'Importe quel CPU

J'ai fini par la suppression de mes références (j'avais ajouté correctement à l'aide de l'onglet projets, et ils servent à construire très bien), la main de l'édition de mon .csproj de fichiers et de suppression bizarre entrées qui ne font pas partie -- et réglage de mes sorties pour le debug et release, x86 et le x64 et une unité centrale pour tous "\bin" -- je l'ai construit une fois, puis re-ajout de la référence (encore une fois, à l'aide de l'onglet projets), et tout a commencé à travailler à nouveau pour moi. Ne pas avoir à redémarrer Visual Studio à tous.

Il semble se produire lorsque vous commander une solution avec plusieurs projets qui ont des liens entre eux, et vous n'avez pas construit avant. Si vous avez des références directement à la dll, au lieu de référencer le projet, vous aurez ce message.
Vous devriez toujours utiliser l'onglet Projets dans le dialogue Ajouter une Référence à ajouter une référence à un projet dans la même solution. De cette façon, VS pouvez connaître le bon ordre pour construire la solution

J'ai eu le même problème. J'ai remarqué que ma db contexte (EF4) qui était situé dans le projet dll n'était pas reconnaître pour une raison quelconque. Je l'ai supprimé et créé une autre à la place. et qui a résolu pour moi.

Je suis d'accord avec la plupart des réponses postées ici. Toutefois, si les solutions proposées ne fonctionnent pas, considérez que vous avez probablement un autre type d'erreur dans votre liste d'erreurs, c'est la prévention de VS pour construire un projet DLL nécessaire pour les autres projets. Alors peu importe l'ordre de la génération ou de la configuration, vous ne serez pas en mesure de se débarrasser de "métadonnées" erreur jusqu'les autres questions sont triés.

J'ai eu le même problème. De supprimer manuellement et ajouter les dll n'a pas aidé. ClassLibraries ne compile pas pour tous les projets et ont disparu dans la ...\bin\Debug dossier pour le projet [parce que j'ai nettoyé solution par erreur]. Depuis la bibliothèque de classe n'a pas de compilation qui signifie qu'il y a peut être quelques erreurs quelque part dans l'un de ces sous-projets.

Solution: Depuis ma dll étaient là pour la ...\bin\Release dossier, j'ai essayé de reconstruire sur le mode de Libération et trouvé une erreur sur une ligne dans l'un des sous-projets. Résolution de l'erreur et de la reconstruction de la solution de s'en débarrasser au large de la erreur de construction.

J'ai eu le même problème et la raison derrière cette question, c'est que le fichier dll du projet de référence est utilisé par un autre processus. Dans mon cas, j'ai été le débogage d'une application et l'application a été attaché avec débogueur visual studio. Lorsque j'ai été re-construction d'une autre application qui utilise le même projet, alors j'ai été faire cette erreur. Après de les attacher, j'ai été en mesure de construire seconde application avec succès.

J'ai aussi eu ce problème aujourd'hui. Le mien a été causé par un dépendance cyclique. Projet Un Projet référencé B et vice versa.

Dans mon cas, lors d'une fusion, il semble que la solution fichier est manquant quelques références de projet. De nouveau manuellement ajouter le projet à la solution, il fixe. Vous pouvez également modifier manuellement le fichier de solution, mais vous devez être prudent et savoir ce que vous faites.

L' ~30 réponse 🙂

Dans VS2015:

• Cliquez-droit sur la Solution
• Sélectionnez Projet De Construction Afin
• Oeil à la liste des projets dans le Projet de l'Ordre de la génération
• Construire chacun de vos projets, dans l'ordre,
• Inspecter la Sortie

Dans mon cas, faire l'étape-par-étape aidé découvert que mon problème est que sans toutes ces erreurs jeté à gauche et à droite.

Si vous avez eu à connaître, j'ai ajouté Cadre de l'Entité (EF) 6.1.3 via NuGet lorsque le projet a été mis pour .NET 4.5.2. Plus tard, j'ai revu à la baisse la .NET Framework 4, et puis l'erreur a été de plus en plus évidents. Via NuGet, j'ai désinstallé EF et re-il ajouté.

Vérifier si l' .vs dossier dans la racine du projet est masqué ou non. Le mien n'était pas (et devrait) depuis que j'ai fait un copier/coller à partir d'un autre pc. La suppression il a résolu le problème, Visual Studio 2015, simplement recréé pour moi.

J'ai eu ce problème lorsque vous essayez d'ajouter une référence de projet, et après beaucoup de recherche et d'essayer beaucoup de choses d'en haut, ma configuration de build et les sorties étaient correctes.

J'ai finalement juste supprimé le \bin et \obj des dossiers à partir de la source et référence du projet.

Honnêtement, je crois que c'était le obj dossier ne contenant pas le bon métadonnées ou endommagé de métadonnées.

Tout est fixé maintenant.

C'était avec Visual Studio 2015 - .NET de 4,6 projets.

Mise à JOUR:

Ci-dessus a travaillé sur la première génération, mais sur les versions ultérieures, il a échoué, j'ai donc fini par recréer le fichier de solution, ainsi que la suppression et de la lecture les packages NuGet qui ont été référencés de manière incorrecte dans mes fichiers de projet, qui fait référence à la mauvaise indicateur de chemin de.

Qui semblait avoir fixé jusqu'à présent sur les versions ultérieures.

Un échantillon de référence à l'intérieur d'un .fichier csproj

<ItemGroup>
    <Reference Include="Antlr3.Runtime, Version=3.5.0.2, Culture=neutral, PublicKeyToken=eb42632606e9261f, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>..\..\packages\Antlr.3.5.0.2\lib\Antlr3.Runtime.dll</HintPath>
    </Reference>
</ItemGroup>

dans mon cas, je travaille sur une branche master. j'ai donc vérifié la branche master, a couru un build puis vérifié ma branche. Il fixe le problème. Si vous êtes déjà sur le maître, je vous suggère de vérifier précédente livraison, puis le construire.