Visual studio - erreur s'est produite "le fichier de métadonnées 'XYZ' n'a pas été trouvé" après la modification continue
Je suis tombé sur une question qui est vraiment énervante.
Lorsque je débogue mon logiciel, tout fonctionne correctement, mais si j'atteins un point d'arrêt et que je modifie le code, lorsque j'essaie de continuer à exécuter, un message d'erreur s'affiche:Metadata file 'XYZ' could not be found
Après avoir regardé pendant un moment, j'ai trouvé quelques problèmes similaires , mais ils concernaient tous un échec de la construction, ce qui n'est pas mon cas (cela ne se produit qu'après la commande edit-continue).
Ce que j'ai essayé jusqu'à présent:
- Mon code est en cours de compilation et en cours d'exécution.
- J'ai nettoyé la solution et redémarré VS.
- Je me suis assuré que le projet du fichier manquant est en cours de construction pour la configuration que j'exécute (dans le gestionnaire de configuration).
- J'ai construit manuellement le projet du fichier manquant.
Quelques informations supplémentaires :
- Peu importe ce que je change, obtenez toujours la même erreur (le changement n'est pas lié au fichier manquant).
- Cela arrive aussi quand je fais une pause et continue (pas seulement des points d'arrêt)
- J'exécute le projet en utilisant une configuration personnalisée (gestionnaire de configuration ...). Lorsque je l'exécute avec la configuration par défaut
Debug, l'erreur ne se produit pas.
Des idées?
Finalement, le problème résolu:
- Nettoyez chaque projet individuellement (clic droit> nettoyez).
- Reconstruisez chaque projet individuellement (clic droit> reconstruire).
- Reconstruisez le projet de démarrage.
Je suppose que pour une raison quelconque, le simple fait de nettoyer la solution avait un effet différent de celui de nettoyer chaque projet individuellement.
Edit:
Selon le commentaire de @maplemale, il semble parfois que l’on supprime et rajoute chaque référence.
Mise à jour 2019:
Cette question a suscité beaucoup de trafic dans le passé, mais il semble que depuis la sortie de VS 2017, elle a attiré beaucoup moins d’attention.
Une autre suggestion serait donc - Mettre à jour une version plus récente de VS (> = 2017) et, parmi d’autres nouvelles fonctionnalités, ce problème sera également résolu
Autant que je sache, cela se produit lorsque les dépendances du projet sont perturbées pour une raison quelconque (alors que toutes les références inter-projets sont toujours intactes). Dans de nombreux cas, ce n'est PAS un problème de code. Et pour ceux qui ont plusieurs projets, les examiner un à la fois n’est PAS acceptable.
Il est facile de réinitialiser les dépendances du projet -
- Sélectionnez tous les projets et faites un clic droit décharger
- Sélectionnez tous les projets et cliquez avec le bouton droit sur recharger
- Reconstruire la solution
Pour ceux qui ont un problème dans leur code ou un autre problème qui cause ce problème, vous devrez évidemment le résoudre en premier.
Une des raisons possibles pourrait être que vous avez mis à niveau certains de vos projets (dans la solution) vers une version supérieure, par exemple. de .NET 4.0 à 4.5 Cela s'est produit dans mon cas lorsque j'ai ouvert la solution dans VS 2013 (créée à l'origine avec VS 2010 et .NET 4.0). Lorsque j'ai ouvert VS 2013, mon projet C++ a été mis à jour vers .NET 4.5 et j'ai commencé à voir le problème.
Généralement, ce type d'erreur est accompagné d'erreurs humaines, par exemple si nous modifions l'espace de nom de manière inappropriée ou si nous modifions les noms de dossiers dans Explorer pour le projet en cours, etc., où le compilateur est parfois incapable de détecter.
Je suis tombé sur la même erreur, pour résoudre ce que j'ai essayé quelques étapes. Veuillez suivre toutes les étapes:
- Solution entière propre
- Cliquez avec le bouton droit sur chaque projet de votre solution, accédez à Propriétés et faites en sorte que votre espace de noms par défaut ainsi que le nom de l'assembly par défaut soient identiques à ceux de votre code (i.e, avant le nom de la classe).
- Vérifiez les noms de dossier pour chaque projet en passant par l'explorateur (où se trouve la solution de votre projet). Si cela ne correspond pas à vos noms de projet, rendez-le similaire (comme étape 2).
- Supprimez toutes vos références de chaque projet correspondant à un autre de la même solution, puis ajoutez-les à nouveau.
- Dans le dossier Your Project Solution, vous trouverez le fichier de projet Visual c #. Faites un clic droit et ouvrez avec le Bloc-notes. Dans vos lignes initiales, vous trouverez des lignes pour chaque projet comme ci-dessous:
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "**Client**", "**Client** \ **Client**.csproj", "{4503E259-0E3B-414A-9074-F251684322A5}" EndProject
Vérifiez à nouveau les noms de dossiers (je les ai mis en gras) et rendez-les similaires à ce que vous avez fait dans étape 2.
Nettoyez à nouveau toute la solution
Construisez la solution (si cela ne fonctionne pas, essayez de construire une personne après avoir nettoyé à nouveau)
Assurez-vous que tous vos projets dépendants utilisent la même version .Net Framework. J'ai eu le même problème causé par un projet dépendant utilisant 4.5.1, alors que tous les autres utilisaient 4.5. Le passage du projet de 4.5.1 à 4.5 et la reconstruction de ma solution ont résolu ce problème.
XYZ n'a pas pu être trouvé car n'est pas encore construit ....
Cliquez avec le bouton droit de la souris sur la solution et cochez Dépendances du projet. L'ordre de construction du projet doit également changer en fonction des dépendances définies.
La seule chose qui a fonctionné pour moi a été de supprimer le fichier Options utilisateur de la solution (.suo) . Notez que ceci est un fichier caché.
Pour localiser ce fichier, fermez votre studio Virsual et recherchez .suo dans l'explorateur de fichiers de votre projet.
PS: , un nouveau fichier .suo sera créé à nouveau lorsque vous reconstruirez votre projet. Espérons que ce fichier nouvellement créé ne vous posera pas de problèmes.
J'espère que cela aidera quelqu'un à se débarrasser de cette erreur angoissante :).
Eh bien, ma réponse n’est pas simplement 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") et 1 erreur indiquant "Impossible d'ouvrir le fichier source (" erreur non spécifiée ")".
J'ai essayé de me débarrasser de l'erreur "Le fichier de métadonnées était introuvable". Pour cela, j'ai lu de nombreux articles, blogs, etc. et trouvé que ces solutions peuvent être efficaces (en les résumant ici):
Redémarrez VS et essayez de construire à nouveau.
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 sous "Construire" sont cochées ou non. Si certains d'entre eux ne sont pas cochés, vérifiez-les et essayez de construire à nouveau.
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, cochez à nouveau et essayez de construire à nouveau.
Ordres de construction et dépendances de projet:
Allez dans 'Explorateur de solutions'. Faites un clic droit sur la solution. Allez à 'Dépendances du projet ...'. Vous verrez deux 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 (par exemple, "projet1") dépendant d'un autre (par exemple, "projet2") tente de générer avant celui-ci (projet2). Cela pourrait être la cause de l'erreur.
Vérifiez le chemin du .dll manquant:
Vérifiez le chemin du fichier .dll manquant. Si le chemin d'accès contient de l'espace ou tout autre caractère de chemin d'accès non valide, supprimez-le et essayez à nouveau de le construire.
Si c'est la cause, ajustez l'ordre de construction.
J'ai eu ce problème pendant des jours! J'ai essayé toutes les choses ci-dessus, mais le problème revenait sans cesse. Lorsque ce message s'affiche, il peut signifier "un ou plusieurs projets de votre solution ne se compilent pas proprement", ainsi les métadonnées du fichier n'ont jamais été écrites. Mais dans mon cas, je n'ai vu aucune des autres erreurs du compilateur !!! J'ai continué à essayer de compiler chaque solution manuellement, et ce n'est que lorsque VS2012 a révélé des erreurs de compilation que je n'avais pas vues auparavant, ce problème a disparu.
Je me suis amusé avec les ordres de construction, pas d'ordre de construction, en référençant les dlls de débogage (qui ont été compilées manuellement) ... RIEN ne semblait fonctionner, jusqu'à ce que j'ai trouvé ces erreurs qui ne se sont pas révélées lors de la compilation de la solution complète !!!!
Parfois, il semble, lors de la compilation, que le compilateur existera sur certaines erreurs ... J'ai déjà vu cela par le passé: après avoir résolu les problèmes, les compilations suivantes affichent de NOUVELLES erreurs. Je ne sais pas pourquoi cela se produit et c'est un peu rare pour moi d'avoir ces problèmes. Cependant, lorsque vous les avez comme cela, il est très difficile d'essayer de savoir ce qui se passe. Bonne chance!
Utilisez-vous un outil de génération de code de base de données tel que SQLMETAL dans votre projet?
Si tel est le cas, vous êtes peut-être confronté à un problème de transition pluraliste ou non pluraliste.
Dans mon cas, j’ai noté que certains anciens noms de table pluralisés (*) (sur lesquels SQLMETAL ajoute, par défaut, une lettre " s " à la fin) les références de table aux classes générées par SQLMETAL.
Depuis, j’ai récemment désactivé la pluralisation des noms , après la régression de classes liées à la base de données, certaines d’entre elles ont perdu leur " s "préfixe. Par conséquent, toutes les références aux classes de table concernées sont devenues invalides. Pour cette raison, j'ai plusieurs erreurs de compilation comme celles-ci:
'xxxx' ne contient pas de définition pour 'TableNames' et aucune méthode d'extension 'TableNames' acceptant un premier argument de type 'yyyy' n'a pu être trouvée (il vous manque une directive using ou une référence Assembly?)
Comme vous le savez, je ne prends que par erreur pour empêcher une Assemblée de compiler. Et c'est l'assembly manquant peut être lié à des assemblys dépendants, entraînant le "fichier de métadonnées 'XYZ' introuvable."
Après avoir corrigé manuellement les références des tables de classes affectées à leurs noms actuels (non structurées), j'ai finalement pu redonner vie à mon projet!
(*) Si option Visual Studio> Menu Outils > Options > Outils de base de données > Concepteur O/R > La pluralisation des noms est activée, un générateur de code SQLMETALl ajoute une lettre " s " à la fin de certaines classes de table générées, bien que table n’ait pas de suffixe "s" sur la base de données cible. Pour plus d'informations, veuillez vous reporter à http://msdn.Microsoft.com/en-us/library/bb386987 (v = vs.110) .aspx
J'espère que ça aide!
Mes 5 centimes.
Ce problème a commencé après une solution de nettoyage en profondeur.
J'ai réussi à résoudre le problème en réglant la configuration de la solution active dans: Construire -> Gestionnaire de configuration à publier. Puis compilez-le et redéfinissez-le pour déboguer à nouveau. La construction a réussi par la suite.
J'ai eu cette erreur à venir. J'ai suivi toutes les solutions ici mais rien n'a fonctionné. J'utilisais Visual Studio 2013 Professional. Je ne pouvais pas faire fonctionner les reconstructions de projets individuels et j'ai finalement compris qu'il y avait un dépendance circulaire dans mes références. Normalement, Visual Studio vous avertit normalement si vous ajoutez une référence à quelque chose qui référence déjà, mais pour une raison quelconque, ce n'est pas le cas ici. J'ai ajouté une référence à un projet qui faisait référence au projet sur lequel je travaillais - et il l'a accepté. VS bug peut-être?
Fermez VS, localisez et supprimez le dossier 'packages' situé en dehors de visual studio. Redémarrer VS et construire -> toutes les dépendances sont réinstallées
J'ai eu le même problème. Dans mon cas, j'avais par erreur que j'avais défini tous les projets en dehors du projet avec la méthode principale en tant qu'application console.
Pour résoudre ce problème, je suis allé dans chaque projet autre que celui ayant une fonction principale et clic droit> propriétés> type de sortie> bibliothèque de classes
Pour une nouvelle construction, il se peut que certaines dépendances ne soient pas installées. Pour moi, c'était Crystal Reports.
cela m'est arrivé parce que j'ai eu un conflit étrange dans les espaces de noms: j'avais AssemblyA avec l'espace de noms AssemblyA.ParentNamespace qui définit ClassA et, dans le même Assembly, un autre espace de noms portant le nom AssemblyA.ParentNamespace.ChildNamespace définit un autre ClassA (mais même nom)
J'avais ensuite dans AssemblyA.ParentNamespace IInterfaceB une méthode qui, au début, renvoie IEnumerable et une classe B implémentant IInterfaceB.
J'avais plus tard modifié la méthode dans ClassB pour renvoyer IEnumerable, mais j'avais oublié de mettre à jour la définition de IInterfaceB. fait référence à AssemblyA ne fonctionne pas et renvoie l'erreur "Le fichier de métadonnées n'a pas été trouvé".
mettre à jour InterfaceB pour qu'il retourne correctement IEnumerable car son implémenteur, ClassB, a résolu le problème. Malheureusement, le message d'erreur était vague et le fait que la compilation ait fonctionné me laisse supposer qu'il y a peut-être quelque chose à corriger dans le compilateur.
Cela se produit lorsqu'un dll de projet échoue et qu'il est référencé par le nombre de projets. Alors corrigez-le d'abord, puis construisez des individus.
cela est dû à la différence de noms entre le nom du dossier et celui de l'espace de nom. Si vous créez un espace de noms portant un certain nom et que vous le renommez par la suite, l’espace de noms aura le même nom. Et la compilation utilisera l'ancien chemin pour trouver le fichier .dll et .exe. Pour éviter cela, ouvrez le fichier .csproj de chaque espace de noms avec un fichier texte et recherchez l'ancien chemin d'accès dans le fichier.
supprimez-le, nettoyez et reconstruisez la solution. Cela a fonctionné pour moi. J'ai passé toute une journée à travailler sur ce problème.
Un collègue rencontrait ce problème et la cause nous échappait. Finalement, nous avons réalisé que le répertoire du projet (et donc le chemin des paquets NuGet) contenait %20 (merci, un outil git gui qui ne doit pas être nommé) et les messages d’erreur montraient que le compilateur recherchait un fichier très similaire. chemin qui regarde mais un qui devait %20, plutôt un espace. Apparemment, quelque chose dans le système de construction effectue quelque part le décodage HTML sur les chemins de systèmes de fichiers locaux.
Renommé le répertoire de travail et tout a commencé à fonctionner.
J'avais ceci et j'ai réussi à le réparer en utilisant cette SO réponse: le fichier de métadonnées '.dll' est introuvable
Je devais désélectionner toutes les cases, cliquer sur Appliquer, réactiver toutes les cases à cocher, puis cliquer de nouveau sur Appliquer, mais le problème était résolu.
J’ai eu ce problème et il a commencé après l’importation de notre solution dans TFS en tant que nouveau projet. Je suis tombé sur ce sujet et j’ai trouvé une solution rapide en s’inspirant de vos réponses.
Tout ce que j'avais à faire, c'est de reconstruire le projet qui aurait perdu son fichier de métadonnées et le tour est joué, le problème est résolu.
Je viens de rencontrer ce problème et après une heure de foutaises, j'ai réalisé que j'avais ajouté à mon produit un fichier aspx qui portait le même nom que l'un de mes Linq-To-Sql = cours.
Classe et page où "File d'attente".
Changé la page à QueueMgr.aspx et tout construit correctement.
Il y a aussi une autre raison idiote que vous devriez vérifier avec patience ... comme cela m'est apparu après avoir perdu 4 heures à chercher des réponses:
L’histoire me dit que j’ai accidentellement changé une petite ligne de code parmi des milliers de fichiers de classe c # et que j’essayais ensuite de reconstruire la solution. Comme vous pouvez l'imaginer, je me suis retrouvé avec plus de 40 métadonnées et plus d'erreurs de compilation et une erreur de compilation parmi celles-ci - ce que je n'ai pas vérifié avec soin, pensant simplement que toutes les erreurs étaient identiques!
après 4 heures de recherche et de vérification accidentelle de ma liste d’erreurs, j’ai trouvé cette erreur de code stupide, je l’ai corrigée, compilée, puis l’erreur a disparu.
Pas une bonne réponse à votre problème, mais espérons que mon cas n’est pas le même que le vôtre.