Fichier de métadonnées… Erreur introuvable lors de la création de projets

Chaque fois que je lance Visual Studio 2008, la première fois que j'essaye d'exécuter le projet, j'obtiens l'erreur CS0006 Le fichier de métadonnées ... est introuvable. Si je reconstruis la solution complète, cela fonctionne.

Quelques informations sur la solution:

• Je construis en mode débogage et Visual Studio se plaint de ne pas trouver dll: s dans le dossier release.

• Les projets dont Visual Studio se plaint sont utilisés par de nombreux autres projets de la solution.

• J'ai changé le chemin de sortie par défaut de tous les projets en ...... \ build \ debug \ ProjectName et ...... \ build \ release \ ProjectName respectivement. (Juste pour obtenir tous les fichiers de construction dans un répertoire)

• J'ai le même problème avec une autre solution.

• La solution a été créée à partir de zéro.

• Il y a 9 projets dans la solution. Un WPF et 8 bibliothèques de classes utilisant dotnet 3.5.

Des idées sur ce qui cause ce problème?

J'ai eu le même problème où "les métadonnées ne pouvaient pas être trouvées". sur la propriété solution, assurez-vous que la case à cocher «build» est cochée dans Build / Configuration Manager pour chaque projet.

Cela est généralement dû à un projet référencé dans une solution différente de celle qui génère l'erreur. Si vous nettoyez l'autre solution ou branchez le code, vous verrez probablement cette erreur. La solution est de faire défiler votre liste d'erreurs "métadonnées non trouvées" et de regarder les références aux projets. 9/10 fois, vous verrez une référence brisée à un projet qui n'est pas dans cette solution. Ajoutez les projets pour corriger les erreurs de référence et reconstruisez. Cela devrait le réparer.

(Je viens de rencontrer ça aujourd'hui, et je l'ai fait dans le passé, et cela a TOUJOURS fonctionné)

J'ai eu ce problème, je ne sais pas si cela aidera, mais le mien a été causé par le fait que deux versions différentes du même projet sont référencées par deux solutions différentes. Lorsque j'ai construit la solution avec la référence au projet correct en premier, la deuxième solution serait bien construite, cependant, si je nettoyais la première solution et essayais de créer la deuxième solution, elle échouerait avec ces messages d'erreur de référence dll.

La solution pour moi était de comprendre que j'avais deux projets avec le même nom qui avaient été accidentellement dupliqués et de supprimer la référence à l'ancien projet incorrect et d'ajouter une référence au nouveau.

Dans tous les cas, il semble que ces messages soient un peu un hareng rouge, je vérifierais votre sortie de construction et trouverais le premier projet qui ne parvient pas à se construire et vérifierais très attentivement les références sur ce projet.

Une autre chose à vérifier est la longueur du chemin ... qui provoque également des erreurs de compilation et de fichier de métadonnées non trouvé ... Je viens de renommer mes dossiers en chemins plus courts et voilá, des classes qui n'étaient pas reconnues et qui sont restées noires, sont devenues bleues simplement en renommant le dossier.

Pour moi, j'avais un projet référencé dans un autre projet. Il n'a pas montré qu'il était cassé dans la liste des références dans la fenêtre de l'explorateur de solutions, mais je l'ai supprimé et lu de toute façon. Il se construit très bien maintenant!

J'ai parcouru toutes ces étapes dans VS2012, mais j'ai continué à rencontrer ce problème lors de la construction de la solution dans son ensemble (les projets individuels se sont bien construits sans erreur).

J'ai constaté que si vous cliquez avec le bouton droit sur votre solution dans l'Explorateur de solutions et sélectionnez «Ordre de génération», vous pouvez voir l'ordre que VS utilise pour reconstruire votre solution. Il est probablement hors de contrôle.

Vous pouvez corriger l'ordre de construction en cliquant sur l'onglet Dépendances et en sélectionnant les projets qui dépendent d'autres projets dans la solution et en vérifiant les projets dont ils dépendent. Une fois que vous avez réussi et que vous avez reconstruit la solution, vous devriez être prêt à partir.

La façon dont j'ai contourné cela dans le passé dans VS2005 ainsi que maintenant dans VS2008 est de m'assurer que toutes les dépendances sont correctes et que les références pointent vers les projets et non vers les dll. Ensuite, parcourez et créez manuellement chaque projet dans l'ordre de dépendance. Une fois le dernier construit, vous pouvez exécuter une version complète de la solution et tout va bien.

Cette réponse est pour référence future pour les autres car je sais que la question date de plus de 15 mois.

À votre santé

Je voudrais faire quelques remarques.

Si vous comptez sur le fichier de solution comme fichier de construction sous MSBuild, assurez-vous que vous ajoutez des projets au fichier de solution dans l'ordre dans lequel vous voulez qu'ils se construisent, c'est-à-dire en fonction de l'ordre de dépendance mutuelle des projets. Cela devient très important si vous avez des projets dans la solution dont dépendent d'autres projets, mais que les références ont été ajoutées en tant que «références» plutôt qu'en tant que «références de projet».

Vous devriez éviter cela comme la peste, mais au cas où vous auriez besoin de le faire, assurez-vous au moins que les projets dépendants apparaissent plus tôt dans le fichier de solution.

Vous devez garder à l'esprit que la façon dont Visual Studio génère l'ordre de génération n'est pas exactement la même que la façon dont MSBuild le fait. En effet, MSBuild dépend principalement du fichier de projet pour lui indiquer quelles sont les dépendances, alors que Visual Studio peut également les enregistrer dans le fichier de solution. Par conséquent, vous pouvez parfois voir des situations dans lesquelles Visual Studio crée parfaitement la solution, mais MSBuild ne peut tout simplement pas le faire.

J'ai eu quelques cas où j'ai dû modifier à la main l'ordre dans lequel les projets apparaissent dans le fichier de solution ainsi que l'ordre dans lequel les projets étaient répertoriés dans l'élément ProjectReferences dans un projet de site Web dans le fichier de solution.

J'espère que les informations ci-dessus vous aideront.

Si vous utilisez des contextes de données LinqtoSQL, par exemple, et que le fichier .designer.cs est manquant, vous obtiendrez l'erreur Le fichier de métadonnées n'a pas pu être trouvé.

Recréer le fichier designer.cs est facile.

Ouvrez le dbml en utilisant la vue xml. Ajoutez une ligne vierge, supprimez-la, puis enregistrez. Cela devrait régénérer votre fichier designer.cs.

Dans certaines circonstances, si vous avez du code dans le code-behind de votre contexte de données, cette solution ne fonctionnera pas. Dans ce cas, retirez le code du code derrière et mettez-le dans le bloc-notes ou quelque chose du genre. Faites l'astuce d'ajouter puis de supprimer une ligne du DC et de sauvegarder. Maintenant, remettez le code et enregistrez-le.

J'ai un problème similaire à chaque fois que je mets à jour le projet depuis SVN.
Une autre solution pour ASP.NET:

1. Fermez l'IDE.
2. Supprimez les fichiers dans C:\WINDOWS\microsoft.net\framework\v…\Temporary ASP.NET File\.

J'ai également rencontré cette erreur et la cause était que le projet se réfère à lui-même. Je n'ai aucune idée de comment c'est arrivé mais je viens de supprimer la référence et le tour est joué

Assurez-vous d'abord que la case à cocher "build" est cochée dans Build -> Configuration Manager pour chaque projet.

Dans le cas où, si vous avez déjà tous les projets sélectionnés dans le menu Build -> Configuration Manager, et que le redémarrage de VS trick ne fonctionne pas non plus pour vous, vous devez trouver la référence du ou des fichiers (peut être dll ou cs) dans votre projet et supprimez ces références manuellement. Ces fichiers / références doivent être affichés avec une icône jaune. L'erreur vous guide définitivement sur le projet de solution que vous devriez examiner.

La raison de cette erreur est que vous avez supprimé manuellement des fichiers dans l'explorateur Windows et que VS n'a pas mis à jour la référence et n'a pas essayé de localiser le fichier qui n'existe plus!

Dans mon cas, j'ai découvert que l'une de mes solutions faisait référence à quelque chose qui n'était pas là sur l'ordinateur (VBIDE). Une fois que j'ai supprimé la référence incriminée, le reste des projets s'est construit correctement. J'espère que cela aide quelqu'un.

Et dans une autre situation, j'ai déplacé du code d'un projet à un autre, et ce morceau de code faisait référence à Json.net. J'ai ajouté manuellement une référence à Json.net mais cela a fait le problème. Je l'ai résolu en installant Json.net via NuGet et cela a fait disparaître le problème. J'espère que cela aide quelqu'un.

La même chose s'est produite. J'ai plusieurs solutions référençant les mêmes projets de bibliothèques (.net 3.5). J'ai remarqué que lorsque l'un était construit en debug / configuration normale, et un autre utilisant une autre directive de compilateur (sqlite / mode local), cela se produisait. Faites simplement construire les deux projets avec les mêmes directives et tout devrait bien se passer.

Si vous avez ajouté un nouveau projet à la solution, vérifiez qu'il se trouve dans la liste de construction (voir le Gestionnaire de configuration)

Je suis resté coincé avec le problème de sauvegarde lorsque je voulais inclure un fichier dll généré par Matlab. Et j'ai finalement résolu le problème en copiant un fichier .ctf, ce qui signifie certificat je suppose, et un .netmodule, nécessaire au bon fonctionnement du .dll, avec le fichier .dll. Et cela a vraiment fonctionné! Donc, ma suggestion est de vérifier si le .dll a besoin d'autres fichiers pour s'entendre.

Windows 7 Édition Intégrale 32 Visual Studio 2008 SQL Server v2005

Je recevais la même erreur. Et j'ai décidé de supprimer et de rajouter les références du projet. Je n'ai pas pu les ajouter car la référence de base de données dans chacun des projets référencés était vide.

Une fois que j'ai réinitialisé la référence de la base de données au paramètre correct, j'ai pu créer sans autre problème. De plus, c'était ma première tentative de reconstruire ce projet après avoir branché le code source dans VSS.

Bonne chance

J'ai eu cette erreur, elle était causée par l'une de mes dépendances de projet où le nom de l'assembly avait été modifié dans le projet, mais la référence n'a pas été mise à jour. Donc, mettre à jour la référence ou renommer l'assemblage le corrigera.

EE - Dans mon cas, le problème était dans le projet qui a le framework Entity, ouvrez le diagramme, faites glisser n'importe quelle table de 2 cm :) et enregistrez, le VS mettra à jour tous ses liens vers la base de données ... construisez ces projets et construisez la solution , Buildssss.

La seule chose qui m'a corrigé (car je n'utilise pas VS2010 sur un compte administrateur) est de déplacer manuellement la variable d'environnement VS120COMNTOOLS des variables système vers les variables utilisateur.

La suppression des entrées de tous les fichiers source qui ne sont plus présents dans le contrôle de code source et le système de fichiers de votre fichier .csproj a fonctionné pour moi.

Approche détaillée:

Eh bien, ma réponse suivante 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 « Build » sont vérifié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 .