Le fichier de métadonnées '.dll " n'a pas pu être trouvé
Je suis en train de travailler sur un WPF, C# 3.0 projet, et j'obtiens cette erreur:
Error 1 Metadata file
'WORK=- \Tools\VersionManagementSystem\BusinessLogicLayer\bin\Debug
\BusinessLogicLayer.dll' could not be found C:\-=WORK=- \Tools
\VersionManagementSystem\VersionManagementSystem\CSC VersionManagementSystem
C'est de cette façon que je référence mon usercontrols:
xmlns:vms="clr-namespace:VersionManagementSystem"
<vms:SignOffProjectListing Margin="5"/>
Il arrive après chaque échec de construire. La seule façon que je peux obtenir la solution à la compilation consiste à commenter toutes mes commandes de l'utilisateur et de re-construire le projet, et puis j'ai décommentez la usercontrols et tout va bien.
J'ai vérifié les ordres de construction et dépendances configurations.
Comme vous pouvez le voir, il semble avoir tronqué le fichier DLL chemin absolu... j'ai lu qu'il y a un bug avec la longueur. Est-ce un problème?
C'est très ennuyeux et avoir de commentaire, de construire, et ne commentez pas, le build est en train de devenir extrêmement fastidieux.
- J'ai eu un problème similaire (obtenir la même erreur qui est indiqué dans le titre) et géré par le nettoyage et la reconstruction du projet. Pour référencer correctement d'autres projets, je n'en ai aucune idée..
- Cette question a une réponse qui serait considérée comme acceptée? Je trouve l'une par @Matt_Bro pour être tout à fait un bon.
- J'ai marqué Matt répondre comme il semble avoir travaillé pour la plupart des gens, cependant cela n'a pas résolu mon problème d'origine. Je pense toujours que c'est lié à la Windows max chemin de limite. Voir ma réponse ci-dessous.
- double possible de le fichier de Métadonnées '...\Release\project.dll " ne peut pas être trouvé dans Visual Studio
- J'ai essayé toutes les réponses ci-dessus et, malheureusement, rien n'a fonctionné dans mon cas. J'ai rencontré avec 2 erreurs 1. Manquant .fichier dll 2. Méthode déjà défini à un autre endroit, avec les mêmes paramètres que j'ai effacé la deuxième erreur, d'abord par la suppression de la fonction, qui a été dupliqué à un autre endroit. Ma première erreur qui est .fichier dll manquant, l'a résolu en son propre. Je veux dire si vous avez plus d'erreur unique avec .dll fichier manquant erreur! Merci d'essayer de résoudre les erreurs de la première. Peut-être .erreur de dll résout sur elle-même!
- Nous avons également obtenir le fichier de méta-données '.dll introuvable problème lorsque vous parrainez un projet dll qui s'est construit sur une version plus récente .Net framework de votre projet en cours.
- La solution à la question similaire, stackoverflow.com/questions/20490857/... a fonctionné pour moi.
- Salut à tous, il y a beaucoup de solutions, et je ne pense pas que j'ai trouver le mien. Mon problème est que je l'ai en double référence, l'un pour le projet de la solution et l'autre pointant vers une DLL dans mon répertoire bin. Supprimer la référence à deux reprises et re-ajouter la référence résolu le mien.
- Le fait que cette chose arrive encore en 2018 me fait de la peine beaucoup. Je ne suis même pas sûr de savoir comment j'ai réussi à le résoudre. C'est comme un VS chose ou quelque chose.
- Est-ce vraiment spécifique à WPF?
- Autre chose à essayer, j'ai résolu toutes les autres erreurs dans la solution et ce problème a disparu.
Vous devez vous connecter pour publier un commentaire.
J'ai juste eu le même problème. Visual Studio n'est pas la construction du projet qui est référencé.
Instructions Écrites:
Capture d'écran Instructions:
release/bin
dossier. Qui n'ont pas le fixer. J'ai fait la même chose pour la configuration debug, puis lerelease/bin
erreur de s'en alla. Microsoft 0/10}
à la fin de la classe de fichier qui a causé les métadonnées d'erreur.Cela peut encore se produire dans les nouvelles versions de Visual Studio (je l'ai juste fait arriver sur Visual Studio; 2013):
Une autre chose à essayer est de fermer Visual Studio et supprimer les
.suo
fichier qui est à côté de la.sln
fichier. (Il va être re-généré la prochaine fois que vousSave all
(ou à la sortie de Visual Studio)).J'ai eu ce problème lors de l'ajout des nouveaux projets de la solution sur une autre machine, puis en tirant les révisions, mais le
.suo
fichier peut être endommagé dans d'autres cas, et conduire à de très étrange Visual Studio comportement, de sorte que la suppression c'est l'une des choses que j'ai toujours essayer.Noter que la suppression de l'
.suo
fichier réinitialiser le projet de démarrage(s) de la solution.Plus sur le
.suo
fichier est ici..suo
fichiers sont cachés. Ainsi, vous aurez à configurer votre explorateur pour afficher les fichiers cachés..suo
fichier est à la fois caché et se trouve dans un caché.vs
répertoire à côté de la.sln
. par exemple: si le fichier de solution estc:\foo\mysolution.sln
recherchezc:\foo\mysolution\.vs\mysolution\v14\.suo
.suo
a le même chemin que dans @Wyck 's commentaire. Bien, le vôtre peut-être dans un v15 dossier et non pas v14..vs
dossier caché à la place qui a également supprimé la.suo
fichier. J'ai réouvert la solution, une fixe sans rapport avec plus d'erreur, et le problème a été résolu.La réponse n'a pas fonctionné pour moi. L'erreur est un leurre pour un autre problème.
J'ai découvert que j'étais ciblant une version légèrement différente de .NET et cela a été signalé comme un avertissement par le compilateur, mais il a été l'origine de la construction à l'échec.
Ce qui devrait avoir été considérée comme une erreur et pas un avertissement.
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 quatre erreurs de ce type (les métadonnées de fichier n'a pas pu être trouvée") avec une erreur en disant " le Fichier Source ne Peut Pas Ê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. trouver ces solutions peuvent être efficaces (les résumer ici):
Redémarrez Visual Studio et essayez de construire à nouveau.
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.
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.
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 deux 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.
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 de combinaisons avec de redémarrer Visual Studio à 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 post de blog: TFS Erreur–Fichier Source ne Peut Pas Être Ouvert ("erreur non spécifiée")
J'ai essayé les étapes mentionnées dans ce billet de 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.
.NET v4.5
projet de.NET v.4
.Dans mon cas, il a été causé par un .NET Framework incompatibilité de version.
Un projet de 3,5 et l'autre qui fait référence au projet 4.6.1.
La fermeture et la réouverture de Visual Studio; 2013 a fonctionné pour moi!
Bien, rien dans les réponses précédentes ont travaillé pour moi, donc il m'a fait penser à pourquoi suis-je en cliquant et en espérant quand, en tant que développeurs, nous devrions vraiment essayer de comprendre ce qui se passe ici.
Il me semblait évident que ce défaut de méta-données de référence de fichier doit être détenu quelque part.
Une recherche rapide .fichier csproj a montré le coupable lignes. J'ai eu une section intitulée <itemGroup> qui semblait être accroché sur le vieux chemin d'accès incorrect.
Donc une solution simple, vraiment:
Veuillez assurez-vous de sauvegarder votre ancien .csproj avant de vous tripoter.
J'ai également rencontré ce problème. Tout d'abord, vous devez créer manuellement vous DLL projet, par clic-droit, de Construire. Ensuite, il sera.
Metadata file ...proj1.dll could not be found
!J'ai eu le même message d'erreur "fichier de méta-données '.dll "n'a pas pu être trouvé", et j'ai essayé plusieurs choses décrites ci-dessus, mais la raison de l'erreur est que j'ai été référencement tiers de fichier DLL qui visait une cible .Version NET plus élevé que mon projet cible .Version NET. Donc la solution a été de changer la cible cadre de mon projet.
Dans mon cas, j'ai mon répertoire d'installation en trompe façons.
Si votre chemin est quelque chose comme "Mon Projet%2c Très Populaire%2c Tests Unitaires%2c Logiciel et Hardware.zip" il ne peut pas résoudre le fichier de métadonnées, nous devrions peut-être éviter certains invalides des mots comme %2c.
De renommer le chemin en nom normal résolu mon problème.
J'ai ajouté un nouveau projet pour ma solution et commencé à faire de ce.
La raison? Le projet m'a été apporté à destination d'une autre .NET framework (4.6 et mes deux autres ont été 4.5.2).
Pour moi, c'était d'essayer de trouver une DLL dans un chemin qui contenait le Projet, mais nous avions déménagé dans un nouveau répertoire. La Solution avait le chemin d'accès correct pour le Projet, mais Visual Studio en quelque sorte mis à la recherche de l'ancien emplacement.
Solution: Renommer chaque Projet de problème - il suffit d'ajouter un caractère ou d'une autre - puis le renommer à son nom d'origine.
Ce doit réinitialiser certains cache global de quelque sorte dans Visual Studio, car cela désactive cette question et plusieurs comme ça, alors que des choses comme Nettoyer ne le font pas.
Pour moi il est venu quand j'ai inclus un nouveau projet à une solution.
Visual Studio sélectionne automatiquement .NET framework 4.5.
J'ai changé de version .NET 4.5.2 comme les autres bibliothèques, et cela a fonctionné.
Pour moi les étapes suivantes travaillé:
Je tirait mes cheveux avec ce problème aussi, mais après avoir essayé les réponses précédentes, la seule chose qui a fonctionné pour moi a été l'ouverture de chaque projet dans ma solution 1 par 1 et de construire individuellement.
Alors j'ai fermé Visuelle Studio; 2013, a rouvert ma solution et il a compilé amende.
C'est étrange, parce que si j'ai cliqué sur chaque projet dans mon Explorateur de solutions et a essayé de construire de cette façon, ils ont tous échoué. J'ai dû ouvrir les seuls dans leurs propres solutions.
Mon instance du problème a été causé par un projet commun qui a un double nom de la classe en elle (avec un nom différent). Il est étrange que Visual Studio n'a pas pu détecter que et, au lieu de simplement sauter le processus de construction.
J'ai eu ce problème dans Visual Studio; 2012, une solution qui a de nombreux projets. La reconstruction de chaque projet dans la solution manuellement dans le même ordre que le Projet d'Ordre de construction (clic droit et reconstruire dans l'Explorateur de solutions), il fixe pour moi.
Finalement, j'ai fait à celui qui m'a donné une erreur de compilation. J'ai corrigé l'erreur, et la solution serait de construire correctement une fois que.
Il ressemble à ce genre d'erreurs liées au fait que Visual Studio n'est pas de fournir des informations correctes sur une erreur. Le développeur n'a même pas de comprendre la raison de l'échec lors de la construction. Il peut être une erreur de syntaxe ou autre chose. En commun, pour résoudre de tels problèmes, vous devriez trouver la racine du problème (par exemple, regardez le journal de génération).
Dans mon cas, le problème était en fait que le
Error List
fenêtre n'avait pas afficher les erreurs. Mais vraiment, il y avait des erreurs de syntaxe; j'ai trouvé ces erreurs dans leOutput
fenêtre, et après fixation, le problème a été résolu.Dans mon cas, le problème était que j'avais supprimé manuellement un non-compilation du fichier qui a été marqué comme "manquant". Une fois que j'ai supprimé la référence à la désormais fichier manquant et recompilé - tout allait bien.
Si vous avez un espace à votre nom de la solution, ce sera aussi causer le problème. Supprimer l'espace à partir de votre nom de la solution, de sorte que le chemin ne contient pas de %20 permettra de résoudre ce problème.
De revenir à cet quelques années plus tard, ce problème est probablement lié à la Windows maximale du chemin d'accès limite:
Nommage des Fichiers, des Chemins et des espaces de noms, Limitation De La Longueur Maximale Du Chemin D'Accès
Dans mon cas, le problème a été causé par une simple erreur de construction,
que, pour une raison quelconque, ne s'affichent pas dans la fenêtre d'erreur.
À cause de cela, Visual Studio système de construction, ne semble pas manquer l'erreur et a essayé de construire des projets dépendants, qui à son tour a échoué avec l'ennuyeux métadonnées message.
La recommandation est -aussi stupide que cela puisse paraître-:
Premier coup d'oeil à votre Fenêtre de Sortie!
Il m'a fallu une demi-heure avant que cette idée m'a frappé...
Moi aussi j'avais le même message d'erreur. Il se cache aussi dans le chemin d'accès ci-dessous.
Le chemin que j'ai évoqué pour le fichier DLL est comme "D:\Assemblies Folder\Assembly1.dll".
Mais le chemin original dans lequel l'assemblée visée était "D:\Assemblies%20Folder\Assembly1.dll".
À cause de ce nom de chemin d'accès de la variation, l'assemblée n'a pas pu être récupérées à partir de son tracé d'origine et, partant, lance le "les Métadonnées ne trouve pas d'erreur".
La solution est dans le Débordement de Pile question Comment puis-je remplacer tous les espaces par %20 en C#?.
J'avais connu le même problème. Dans mon cas, j'avais référencé à un projet de bibliothèque de classes avec plus de .Net version de mon projet et VS n'a pas de construire le projet et a soulevé la même erreur que vous avez posté.
J'ai simplement mis .Net version de mon projet de bibliothèque de classes(celui qui avait brisé le construire) identique à la .La version Net de projet référencé et le problème est résolu.
Simplement en indiquant le flagrant: si vous n'avez pas de "Afficher la fenêtre de sortie lors de la build commence" activée, assurez-vous que vous remarquez si votre construction est un échec (avec un petit "build failed erreur" en bas à gauche)!!!!
J'ai eu ce message d'erreur lorsque j'essaye de publier une application web. S'est avéré qu'une des propriétés de la classe a été enveloppé dans
mais les biens de consommation n'a pas été. La publication a été faite dans la Version de la configuration sans
DEBUG
symbole, évidemment.Basé sur le message d'erreur je ne crois pas que le chemin d'accès au fichier est tronqué. Il semble juste être incorrect. Si je suis en train de lire le message correctement, il semble être à la recherche pour le fichier DLL à ...
Ce n'est pas un chemin d'accès valide. Est-il possible que vous avez une définition de macro dans le processus de construction définie à une valeur non valide?
Cette erreur peut être affiché si vous utilisez de faux assemblées. La suppression des faux conduit à la réussite de la réalisation du projet.
Je suis en cours d'exécution Visual Studio; 2013.
Il semble que les dépendances de construction étaient incorrectes. La suppression de l' *.suo fichiers ne régler les problèmes que j'avais.
Pour mon cas, c'était que j'avais commenté des classes spécifiques (vide) de l'espace de noms:
Quand j'ai enlevé l'espace de noms de code et à l'importation (à l'aide des commandes de celui - ci- il résolu le problème.
Dans la construction, il disait aussi, avec les DLL manquantes de fichier du projet:
Retrait de la
packages
dossier contenant NuGet dans le dossier de la solution a fonctionné pour moi. Après la reconstruction de tout ce qui a de nouveau fonctionné. VérifierReferences
dans la solution et vérifier les références qui ont un triangle jaune.Image d'exemple:
J'ai eu une classe dans 4.6.1 se référant à une interface qui a été dans 4.6.2... la mise à niveau de la classe de 462 fixé.
J'ai eu le même problème. Dans mon cas, le projet serait encore construire en mode release et c'était juste quand j'ai essayé de construire en debug qu'il a échoué.
Ce que j'ai fait pour résoudre la question était simplement de copier tous les fichiers dll (et d'autres fichiers de mon dossier de version) dans mon dossier de débogage. Après avoir fait cela, pour chaque projet, les erreurs fondu.
J'ai eu ce problème parce que
.nuget\NuGet.exe
n'a pas été inclus dans mon référentiel. Bien que j'ai activéDownloadNuGetExe
NuGet.des cibles, il a signalé une erreur de proxy lorsque vous essayez de le télécharger. Cela a provoqué le reste du projet s'appuie à l'échec.J'ai reçu ce message d'erreur après l'ouverture d'un projet dans lequel Entity Framework a été référencé, j'ai donc supprimé ces références, et réinstallé Entity Framework version 6.0.0.0 par pthe acket gestionnaire de cette façon:
L'erreur était toujours à l'affiche, donc j'ai pensé que ces références étaient là parce qu'il y avait une ancienne version de l'Entity Framework soi-disant "préinstallé" sur le projet, mais il n'était pas vraiment de travail.
Je suis donc allé jusqu'au fichier
packages.config
et remarqué qu'il y avait une autre référence:Puis j'ai supprimé la ligne, à nettoyer et reconstruire le projet et le récipient de solution, et il a finalement travaillé.
J'ai eu un problème similaire quand j'ai décompilé une très ancienne bibliothèque, qui a été déployée dans un environnement de production, mais le code source a été perdu.
Que j'ai pris .dll, décompilé et a généré des projets et la solution. J'ai été incapable de construire la solution en raison de plusieurs erreurs de ce genre.
Conseils dans les réponses précédentes n'ont pas d'aide, mais après un certain temps, j'ai remarqué l'absence de références dans certains projets à plusieurs assemblées comme System.dll.
Suppose qu'il y a Un projet dépend de projet B. Il n'y a aucune référence à System.dll dans le projet B, mais l'erreur après la construction était comme "fichier de Métadonnées 'B.dll" ne peut pas être trouvé".
Il n'y a pas d'erreur sur le manque de System.dll dans le projet B.
Ajoutant une référence sur les bibliothèques comme System.dll dans le projet B a résolu le problème.
(Le système.De Données, Système D'.DirectoryServices, etc.)
Dans mon cas, ces erreurs ont été causés par une certaine corruption dans le gestionnaire de package NuGet. Sous-projets de la solution n'étaient pas en train de se construire, mais aucune erreur n'a été montrer à cause de l'métadonnées des erreurs.
Une fois tous les packages NuGet ont été corrigées, le projet pourrait s'appuyer de nouveau correctement.
Dans mon cas, j'ai eu cette erreur parce que, l'un de mes projet à un autre .NET framework version de les autres de la solution. J'ai utilisé le gestionnaire de packages NuGet pour installer NLog, donc, je pense, il a installé pour le .Net version de ce projet.
J'ai essayé toutes les solutions de ce post, mais aucun n'a été en travail. J'ai enlevé NLog, nettoyé la solution et trid pour compiler: Même chose, CS006 erreur.
Il était quand je l'ai supprimé tous les fichiers dans
obj\Debug
de ce projet que la solution compilé.Dans mon cas, certains projets de la solution ont été ciblées pour CPU, certains d'entre eux pour x86. L'erreur de compilation disparu après l'unification de la plate-forme cible à travers la solution.
Mon problème est venu quand je l'ai écrit en c# 7 code, mais le projet a été avec l'ancienne version .net framework
Dans mon cas personnel, je n'avais pas réussi à ajouter une référence à l'un des projets de la solution et c'est ce qui donnait des coups de l'erreur pour moi.
aaaaaand six ans plus tard, lors d'une mise à niveau de Visual Studio 2015, le même problème. Parce que cette solution n'est pas dans cette liste, je suis en ajoutant à cela.
Deux référencé dll ont été dans le c:\windows\system32... le dossier.
En les déplaçant vers un non système de dossier et d'ajouter une référence vers le nouveau dossier fixe-il enfin. Le reste des questions est en effet ce que les autres ont dit ici déjà
La cause du problème peut être que vous avez mixte ajout de références à des fichiers DLL et les projets de la solution.
Si vous avez des projets A, B, et C:
Vous pouvez construire chaque projet séparément, mais vous ne pouvez pas reconstruire une solution se terminant par: fichier de Métadonnées 'C.dll" ne peut pas être trouvé.
La modification de la référence à partir d'un fichier à un projet dans la solution ne permet pas.
Dans mon cas, c'était ReSharper être muet et, même si mes objectifs du projet C# 6 j'ai été offerts refactorings utilisation de C# 7-que les fonctionnalités.
Pour cette raison, j'ai fini par changer ce code,
dans ce code:
Pour une raison quelconque ayant les getter et setter à l'aide de l'expression des corps faits au compilateur que les métadonnées d'erreur au lieu d'une erreur de syntaxe.
J'ai été confronté à ce problème. Dans mon cas, plusieurs projets C# ont été référencé en tant que fichiers DLL. Toute erreur de compilation dans un projet qui est utilisé comme un fichier DLL (dans d'autres projets) aboutirait à un déluge d'erreurs. La raison en est, le temps de compilation d'erreur empêche la création de la DLL correspondante de fichier, et il en résulte une série d'erreurs dans les projets qui font référence à la DLL manquante fichier.
Par conséquent, lors de la reconstruction dans l'Explorateur de solutions (en ignorant le trivial moment de la compilation des erreurs), une bande de "fichier de métadonnées .dll n'a pas pu être trouvé" les erreurs vont se produire (vous faire penser à quel mal que vous avez fait d'autre que d'une simple reconstruction).
Si vous êtes confrontés à ce problème, la meilleure solution est de nettoyer la solution, puis la construction de chaque projet, un par un pour savoir de quel projet est d'initier l'erreur.
En tant qu'utilisateur @burzhuy points, il peut être important de regarder la
Output
fenêtre, et pas seulement lesError List
fenêtre.Dans mon cas, j'étais en train de faire des modifications à la Roslyn compilateur. Ses projets de construction et d'exécuter un supplément de vérifier pour voir si le public les champs sont cohérents avec ce qui a été défini comme le compilateur de l'interface publique, sinon il se produit une RS0016 ou RS0017 erreur. J'avais ajouté un couple de champs publics, et fixe le RS0016 erreur par survol de la souris sur l'erreur et en sélectionnant "Ajouter à l'API publique".
Plus tard, j'ai changé mon esprit et ému tout le public des champs d'une classe différente. Pour une raison quelconque, cela produit le "fichier de Métadonnées n'a pas pu être trouvé d'erreur", et en plus je jouait avec le plus d'erreurs que j'ai eu.
Vous avez besoin de trouver le bon
PublicAPI.Unshipped.txt
fichier (dans mon cas c'étaitE:\Roslyn\32414\src\Compilers\Core\Portable
) et de l'éditer manuellement pour supprimer les lignes qui ne sont plus pertinents.J'ai d'accord tous les précédents juste une différence.
Dans mon cas: je suis à l'aide de Visual Studio 2019. J'ai fermé VS-2019 et ouvert avec VS-2017. et de reconstruire le projet tout fonctionne très bien!
Pour qui, à mon avis, la date est: 4/19/2019
J'ai découvert que si vous supprimez Microsoft.CSharp assemblée comme une référence dans le projet, vous obtiendrez cette erreur.
Vérifier l' .csproj fichier de projet principal. Visual Studio n'est pas propre qu'au cas où vous retirez de projets ou de modifier les références dans la solution.
J'avais de vieux projets référencés trois fois dans le .fichier csproj et compiler ont montré que cette erreur de ceux qui ont été retirés des projets.
Wow, il semble que cette erreur peut venir de partout.
De toute façon, j'ai ajouté un nouveau WebAPI contrôleur pour mon application MVC et il obtenu automatiquement toutes les références de NuGet. Peu plus tard, j'ai enlevé les références du NuGet de l'INTERFACE utilisateur, mais j'ai oublié de supprimer les fichiers et leur utilisation (c'est à dire
System.Http
).Pour une raison quelconque, l'erreur que j'ai été reçu a ce, avec un simple avertissement à propos d'une variable n'est pas utilisée.
J'ai commenté la variable pour se débarrasser au moins de l'avertissement et de la reconstruction m'a indiqué de tous les fichiers qui ont été en utilisant le non-existant de référence. Après la suppression de ces fichiers, tout est OK.
Je suis tombé sur cette erreur avec Visual Studio; 2015, lorsque j'ai enlevé le type d'annotation à partir d'un appel à une méthode d'extension, qui a laissé seulement le vide crochets derrière.
Ainsi, au lieu de
obj.extensionMethod<Type>()
j'avaisobj.extensionMethod<>()
.Je voudrais classer cela comme un bug dans Visual Studio car je ne vois pas comment l'erreur peut produire cette erreur.
Aucune des solutions précédentes travaillé pour moi, donc je vais partager ce qui l'a fait.
J'ai eu ce problème après la fusion de certaines nouvelles bibliothèques de classe, d'une autre branche qui se rapportent à chacun des autres. Supprimer les références, dans les projets et de les recréer enfin résolu le problème. Apparemment Visual Studio avait fusionné sur les mauvais chemins d'accès de fichier.
Ce problème peut se produire en raison d'une erreur de syntaxe dans ton code qui peuvent ne pas être visibles à cause de la Méta Données d'erreur. Alors révisez votre fichier source avant de faire des actions dans les réponses précédentes.
Pour moi, le problème était que j'avais deux fenêtres de Visual Studio ouvert, mon projet était en cours d'exécution dans le debug dans une fenêtre, et j'ai essayé d'en construire un autre.
J'ai eu à arrêter le débogage, puis il permettez-moi de construire avec succès.
Dans mon cas, j'ai eu ce message d'erreur pour la simple raison que, après l'obtention de la dernière version du projet de TSF, le mauvais projet de la solution a été marqué comme projet de démarrage. Le choix d'un projet comme projet de démarrage résolu pour moi.
J'ai eu le même problème et une autre solution.
La question:
Une seule solution, de multiples Projets. La principale application qui utilise certains des autres résultats échoué, en disant:
SCC : erreur CS0006: fichier de Métadonnées 'C:\Repos\TheApplication\TheApplicationCommon\bin\Debug\TheApplication.dll" ne peut pas être trouvé
Mais en réalité, ce Projet a généré
C:\Repos\TheApplication\TheApplicationCommon\bin\Debug\TheApplicationCommon.dll
Un autre projet qui utilise également la même dll compilé parfaitement.
Avant j'ai mis à jour interne NuGet package utilisé PostSharp 3.x.x.x et utilise maintenant PostSharp 4.x.x.x. Et ma solution a été de l'ajouter à mon *.csproj fichier:
Une autre Solution->Propre, une autre Solution->Reconstruire et il fonctionne en local et sur le serveur de build.
Espère que cela aide quelqu'un. Le fil est vieux et assez long, mais cette question revient souvent et je n'ai pas vu cette solution pour le moment. Btw, à l'aide de Visual Studio 2017 (15.8.x).
J'ai eu le même problème dans VS2019. Voici ce que vous devez faire:
J'ai vu cette erreur parce que j'ai eu la ligne suivante dans mon code (qui ressemble à une je pensais toujours en mode SQL):
Visual studio (2017) n'ont signalé aucune des erreurs lors de la conception ou de la compilation cependant, le projet ne serait pas construire et a donné le "manque .dll erreur". Sur le changement de la ligne erronée de:
Le problème a été résolu.
Très étrange! J'ai essayé toutes les réponses précédentes et, malheureusement, rien n'a fonctionné dans mon cas.
J'ai rencontré deux erreurs:
J'ai effacé la deuxième erreur, d'abord par la suppression de la fonction, qui a été dupliqué à un autre endroit.
Ma première erreur qui est .fichier dll manquant, l'a résolu en son propre.
Je veux dire, si vous avez plus d'une seule erreur, le long de avec le .dll fichier manquant erreur, s'il vous plaît essayer de résoudre les erreurs de la première. Peut-être l' .erreur dll de la résoudre sur son propre!
J'ai été confronté à ce problème après
getting latest
(Team Foundation Server (TFS) de commande).Après la résolution de conflits, j'ai trouvé l'aide d'une instruction pour un
namespace that does not exist in the project
.J'ai donc enlevé que
using
instructionclean and rebuild
, et tout était OK.J'ai commencé à avoir ce problème après le changement de la solution de beaucoup, les étagères les changements et la défaire.
Seule façon de le résoudre est la suppression et l'ajout de nouveau la cartographie de TSF pour mon dossier local.
Aucun des dizaines de réponses jusqu'à présent fonctionné pour moi. Dans mon cas, j'ai aussi eu l'erreur:
Cela est apparu à côté de "fichier de méta-données '.dll "n'a pas pu être trouvé" erreurs sur la construction, mais il a disparu peu de temps après, comme des erreurs parfois faire comme les IDE "rattrape".
Double-cliquant sur l'erreur de le trouver, et en supprimant le code fautif, il fixe.
Sinon, vous pouvez essayer ceci dans Visual Studio:
Menu Projet → <nom du Projet> Propriétés → Construire → bouton Avancé → Version en Langue → C# <dernière version mineure> (par exemple, "C# 5.0")
Et qu'il fixe aussi.
Ça ressemble à du "fichier de méta-données '.dll "n'a pas pu être trouvé" est souvent le symptôme d'autres problèmes sous-jacents, de sorte que si aucun des meilleures solutions de travail pour vous, vérifiez les autres erreurs et d'avertissements et d'essayer de trouver la vraie question.
Dans mon cas, le réglage de la cible cadre résolu le problème:
Clic droit sur le projet et sélectionnez Propriétés
Dans Application, changement Cible cadre de la même façon que le projet principal (par exemple ".NET Framework 4.5").
Dans mon cas, j'avais un tas d'autres erreurs de build (certains simples conversions de type) avec celui-ci, j'ai été de me gratter la tête à essayer de résoudre ce problème, et je n'étais pas en se concentrant sur les autres erreurs.
Ce que finalement résolu mon problème est que j'ai résolu toutes les autres construire erreur, puis-je construire de nouveau et de construire avec succès.
Donc, dans le cas où vous avez d'autres erreurs de build avec manquant, fichier DLL erreur, et rien d'autre ne fonctionne pour vous, alors essayez de corriger les autres erreurs, d'abord, puis construire la solution à nouveau.
Pour moi le problème a été une erreur qui n'est pas venu jusqu'à la sortie de la construction, à savoir, j'ai eu deux classes utilitaires qui étaient dans les différents espaces de noms, d'abord. J'ai changé l'espace de noms du deuxième match de la première (sans savoir qu'il y a un autre utilitaire de la classe dans le premier), et c'est lorsque cette erreur a commencé à venir.
J'imagine que la sortie de génération d'erreur refait surface, parce que la Logique de la Couche de la bibliothèque de fichier DLL n'a pas pu être construit, et l'application ne pouvais pas le trouver.
La solution était de revenir à la deuxième classe utilitaire pour un espace de noms différent et c'est quand le réel les erreurs de build a commencé à verser dans. Après le tri la construction est allé par le biais de l'amende juste.
Comme un aperçu, si aucune des solutions précédentes ne fonctionne pas pour vous, vous pourriez avoir supprimé les erreurs dans le code que Visual Studio ne s'affiche pas, alors essayez de recommencer le suivi de vos étapes de codage et de vérification pour les éventuelles irrégularités.
PS: C'était dans Visual Studio; 2015 Community Edition
L'IDE de Visual Studio ne fait pas tout bâtiment, derrière les coulisses, l'Msbuild application. Le VS IDE essentiellement construit la projet de fichier qui est utilisé par Msbuild et assez souvent il fait des erreurs, si vous le laissez à l'IDE à la figure des choses sur son propre. Si vous avez l'
Metadata file '.dll' could not be found
erreur, il est probablement dû au fait que la bonne/prévu assemblées ne sont pas trouvés. Alors peut-être que Visual Studio a peut-être la création d'un fichier de projet pour un 4.5 cadre d'application, et s'attendent à 4,5 assemblées, alors que vous êtes de référencement 4.0 assemblées. Regardez donc vos paramètres Visual Studio pour les incompatibilités ou aller dans le fichier de projet vous-même, et de corriger manuellement en spécifiant le chemin d'accès correct<Reference Include="C:\\correct path to assembly\\yourAssembly.dll" />
.Dans mon cas, à l'intérieur de mon
Web.config
fichier, la modification de ceà ce
fixe mon problème
Lorsque j'ai fait construire, il serait normalement afficher les erreurs de ce genre dans Visual Studio 2017:
Mais parfois, une erreur de ce genre de spectacle pour un couple de secondes, puis elle allait disparaître et revenir au message ci-dessus:
J'ai donc passé du temps dans la résolution de la première erreur, mais le vrai problème s'est avéré être en raison de la deuxième erreur. D'abord j'ai dû supprimer tous les /bin et /obj répertoires, puis, j'ai aussi supprimé le .suo fichiers comme indiqué ci-dessus. Cela m'a permis de réduire le problème à un problème d'interface.
Dans mon interface, j'ai eu ceci:
Mais dans mon application, j'ai eu ce code:
La construction est terminée avec succès après j'ai mis à jour l'interface de ce:
Donc il semble que la mise en cache dans VS causé à continuer à montrer la CS0006 d'erreur lorsque le problème a été le CS1503 erreur.
Dans mon cas, j'ai résolu ce problème en remarquant que j'avais fait référence à un .Net Framework 4.7 projet comme une dépendance sur un .Net Framework 4.6.1 le projet. Après la migration d'un projet de 4,7 à 4.6.1 ma demande compilé normalement
Dans mon cas, il m'est arrivé quand j'étais référencement NuGet packages localement et déplacé leur répertoire à un autre endroit, j'ai changé le chemin d'accès à l'intérieur de
NuGet.Config
mais malheureusement, j'ai découvert que je devrais changer le.csproject
manuellement les fichiers à mettre à jour le chemin de référence, mais le message d'erreurCS0006
était loin de décrire ce problème.Généralement, il se produit également lorsqu'il y a une référence à la DLL qui ne pouvait pas être trouvé, pour être en mesure d'identifier question de recherche, vos références dans le projet avec le problème que vous trouverez quelques références avec l'icône d'avertissement associé avec eux, essayer de corriger ces et il devrait fonctionner comme prévu.
Beaucoup de ces réponses sonore en phase d'essai et d'erreur. Dans mon cas, c'était simple: le référencés dll n'a pas été trouvée dans un lieu donné.
Si vous voyez des erreurs de build, typiquement dans ce cas, la construction se plaint beaucoup de dll. La clé est de trouver la bonne dll est manquant. Dans mon cas, l'un des projets dans ma solution a une conséquence directe de la dll de référence au lieu d'un projet de référence. Donc, j'ai besoin de construire le projet, que les résultats de cette dll avant de construire l'échec d'une solution assurez-vous que le défaut de solution trouve la dll manquante dans un lieu donné.
Wow.. c'était simple, mais assez difficile à mettre en mots.
Ce problème peut se produire parce que vous êtes à l'aide de fonctionnalités qui ne sont pas pris en charge par la version de .net choisi pour le projet.
Dans mon cas, la raison en est que j'ai utilisé ?? l'opérateur de vérifier la nullité et de jeter l'exception.
Assez étrange qu' VS n'a pas l'informer de la raison du problème dans la liste des erreurs de build.
Mais vous pouvez trouver cette information dans le Sortie journaux de la construction.
La suppression de la corbeille/obj dossiers, puis de reconstruire le projet a fonctionné pour moi.
Dans mon cas, je crois que ce qui s'est passé, j'ai vécu un moment de l'exécution d'erreur la première fois que j'ai construit le projet donc mon fichier dll n'a pas été pas généré.
Ce qui s'est passé lorsque le référencement d'un projet à partir d'un autre. Le projet que je faisait référence a été le seul avec ce problème.
Dans mon cas, le dossier parent de la solution a un
%20
dans le nom. J'ai renommé le dossier parent en retrait de la%20
et la question suis fixé.J'ai été confronté à ce problème. Dans mon cas, j'ai supprimer tous les bin et obj dossiers de tous les projets puis cette erreur se résoudre pour moi. Essayez ceci pour un plus essayer de résoudre le problème
J'ai eu ce problème après la mise à jour de la dll/nuget.
Je pourrais résoudre manuellement en modifiant le .fichier csproj. Surtout la version n'était pas mis à jour dans le fichier.
Par exemple :
Visual Studio 2019 cela a fonctionné pour moi:
.vs
dossier