Le fichier de métadonnées '.dll' est introuvable
Je travaille sur un projet WPF, C # 3.0, 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
Voici comment je fais référence à mes contrôles utilisateur:
xmlns:vms="clr-namespace:VersionManagementSystem"
<vms:SignOffProjectListing Margin="5"/>
Cela se produit après chaque construction échouée. La seule façon d'obtenir la solution à compiler est de commenter tous mes contrôles utilisateur et de reconstruire le projet, puis de ne pas commenter les contrôles utilisateur et tout va bien.
J'ai vérifié les configurations des ordres de construction et des dépendances.
Comme vous pouvez le constater, il semble avoir tronqué le chemin absolu du fichier DLL ... J'ai lu qu'il y avait un bogue avec la longueur. Est-ce un problème possible?
C'est très énervant et de devoir commenter, construire, et commenter, la construction devient extrêmement fastidieuse.
Je viens d'avoir le même problème. Visual Studio ne construit pas le projet référencé.
- Cliquez avec le bouton droit sur la solution, puis cliquez sur Propriétés.
- Cliquez sur Configuration à gauche.
- Assurez-vous que la case à cocher sous "Construire" du projet introuvable est cochée. Si cette case est déjà cochée, décochez-la, cliquez sur Appliquer et cochez à nouveau les cases.
Cela peut encore se produire dans les versions plus récentes de Visual Studio (je viens de le faire sur Visual Studio 2013):
Une autre chose à faire est de fermer Visual Studio et de supprimer le fichier .suo situé en regard du fichier .sln. (Il sera re-généré la prochaine fois que vous Save all (ou quitterez Visual Studio)).
J'ai rencontré ce problème en ajoutant de nouveaux projets à la solution sur une autre machine, puis en extrayant les révisions, mais le fichier .suo peut également être corrompu et entraîner un comportement très étrange de Visual Studio. les choses que j'essaye toujours.
Notez que la suppression du fichier .suo réinitialisera le ou les projets de démarrage de la solution.
Plus sur le fichier .suo est ici .
La réponse suggérée n'a pas fonctionné pour moi. L'erreur est un leurre pour un autre problème.
J'ai découvert que je visais une version légèrement différente de .NET et cela a été signalé comme avertissement par le compilateur, mais cela causait l'échec de la construction.
Eh bien, ma réponse n’est pas simplement le résumé de toutes les solutions, mais elle offre plus que cela.
Section 1):
Solutions générales:
J’ai eu quatre erreurs de ce type («fichier de métadonnées introuvable») ainsi qu’une erreur disant «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 Visual Studio et essayez à nouveau de construire.
Allez dans 'Explorateur de solutions'. Faites un clic droit sur la solution. Allez à Propriétés. Accédez à '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 reconstruire.
Ordre de construction et dépendances de projet:
Allez dans 'Explorateur de solutions'. Faites un clic droit sur la solution. Allez dans '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.
Section 2):
Mon cas particulier:
J'ai essayé toutes les étapes ci-dessus avec différentes permutations et combinaisons avec le redémarrage de Visual Studio à quelques reprises. Mais cela ne m'a pas aidé.
C’est pourquoi j’ai décidé de supprimer une autre erreur que je rencontrais ("Impossible d’ouvrir le fichier source (" Erreur non spécifiée ")").
Je suis tombé sur un article de blog: Erreur TFS - Impossible d’ouvrir le fichier source (‘Erreur non spécifiée‘)
J'ai essayé les étapes mentionnées dans ce billet de blog et je me suis débarrassé de l'erreur 'Impossible d'ouvrir le fichier source (' erreur non spécifiée ')' et étonnamment je me suis débarrassé d'autres erreurs ('fichier de métadonnées pourrait ne pas être trouvé ') aussi.
Section 3):
Morale de l'histoire:
Essayez toutes les solutions mentionnées dans la section (1) ci-dessus (et toute autre solution) pour éliminer l’erreur. Si rien ne fonctionne, conformément au 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 source et le système de fichiers de votre fichier .csproj}.
Dans mon cas, cela était dû à une incompatibilité de version .NET Framework.
Un projet était 3.5 et l'autre projet de référencement 4.6.1.
Fermer et réouvrir Visual Studio 2013 a fonctionné pour moi!
Eh bien, rien dans les réponses précédentes ne fonctionnait pour moi, alors je me suis demandé pourquoi je cliquais et espérant qu'en tant que développeurs, nous devrions vraiment essayer de comprendre ce qui se passe ici.
Il me semblait évident que cette référence de fichier de métadonnées incorrecte doit être conservée quelque part.
Une recherche rapide dans le fichier .csproj a montré les lignes de culpabilité. J'avais une section appelée <itemGroup> qui semblait être accrochée à l'ancien chemin de fichier incorrect.
<ItemGroup>
<ProjectReference Include="..\..\..\MySiteOld\MySite.Entities\MySite.Entities.csproj">
<Project>{5b0a347e-cd9a-4746-a3b6-99d6d010a6c2}</Project>
<Name>Beeyp.Entities</Name>
</ProjectReference>
...
Donc, une solution simple vraiment:
- Sauvegardez votre fichier .csproj.
- Recherchez les chemins incorrects dans le fichier .csproj et renommez-les correctement.
S'il vous plaît assurez-vous de sauvegarder votre ancien fichier .csproj avant de jouer du violon .
J'ai aussi rencontré ce problème. Tout d'abord, vous devez construire manuellement votre projet DLL, par un clic droit, Construire. Alors ça va marcher.
J'ai eu la même erreur "Le fichier de métadonnées '.dll' est introuvable" et j'ai essayé plusieurs choses décrites ci-dessus, mais la raison de l'erreur était que je faisais référence au fichier tiers DLL qui visait un La version .NET plus élevée que mon projet cible la version .NET. La solution a donc été de changer le cadre cible de mon projet.
J'ai ajouté un nouveau projet à ma solution et j'ai commencé à l'obtenir.
La raison? Le projet que j'ai introduit ciblait un framework .NET différent (4.6 et mes deux autres étaient 4.5.2).
Dans mon cas, mon répertoire installé est erroné.
Si le chemin de votre solution ressemble à "Mon projet% 2c Très populaire% 2c Test de l'unité% 2c Logiciels et matériels.Zip", il ne peut pas résoudre le fichier de métadonnées. Nous devrions peut-être éviter certains mots non valides, tels que% 2c.
Renommer le chemin en nom normal a résolu mon problème.
Pour moi, cela s’est produit lorsque j’ai intégré un nouveau projet à une solution.
Visual Studio sélectionne automatiquement .NET Framework 4.5.
J'ai changé pour la version .NET 4.5.2 comme les autres bibliothèques, et cela a fonctionné.
Je me tirais les cheveux avec ce problème aussi, mais après avoir essayé les réponses précédentes, la seule chose qui fonctionnait pour moi était d'ouvrir chaque projet de ma solution 1 par 1 et de les construire individuellement.
Ensuite, j'ai fermé Visual Studio 2013, rouvert ma solution et tout a bien été compilé.
C'est étrange, car si je cliquais sur chaque projet dans mon Explorateur de solutions et tentais de le construire de cette façon, ils échouaient tous. Je devais les ouvrir seuls dans leurs propres solutions.
Pour moi, les étapes suivantes ont fonctionné:
- Trouvez le projet qui ne construit pas
- Supprimer/ajouter des références aux projets au sein de la solution.
Pour moi, il essayait de trouver une DLL dans un chemin qui contenait auparavant le projet, mais nous l'avions déplacé dans un nouveau répertoire. Le chemin d'accès au projet était correct pour la solution, mais Visual Studio continuait à chercher dans l'ancien emplacement.
Solution: renommez chaque projet problématique - ajoutez simplement un caractère ou quoi que ce soit - puis renommez-le sous son nom d'origine.
Cela doit réinitialiser un certain type de cache global dans Visual Studio, car cela élimine ce problème et plusieurs autres, mais des opérations comme Nettoyer ne le font pas.
Mon exemple du problème est dû à un projet commun contenant un nom de classe en double (sous un nom de fichier différent). Il est étrange que Visual Studio n’ait pas pu détecter cela et qu’il ait simplement fait sauter le processus de construction.
J'ai eu ce problème dans Visual Studio 2012 dans une solution comportant de nombreux projets. La reconstruction manuelle de chaque projet dans la solution dans le même ordre que l'ordre de construction du projet (clic droit et reconstruction dans l'Explorateur de solutions) a résolu le problème.
Finalement, j'en ai trouvé un qui m'a donné une erreur de compilation. J'ai corrigé l'erreur et la solution se construirait correctement par la suite.
Dans mon cas, le problème était dû à une simple erreur de construction,
erreur CS0067: l'événement 'XYZ' n'est jamais utilisé
que, pour une raison quelconque, n'apparaissait pas dans la fenêtre d'erreur.
À cause de cela, le système de construction de Visual Studio a semblé manquer l'erreur et a tenté de générer des projets dépendants, ce qui a échoué avec le message de métadonnées gênant.
La recommandation est-aussi stupide que cela puisse paraître-:
Regardez d'abord votre fenêtre Output!
Il m'a fallu une demi-heure avant que cette idée me vienne ...
Moi aussi j'ai eu la même erreur. Il se cache comme dans le chemin ci-dessous ... Le chemin auquel j'ai fait référence pour le fichier DLL ressemble à "Dossier D:\Assemblies\Assembly1.dll".
Mais le chemin d'origine dans lequel l'Assemblée se référait était "D:\Assemblies% 20Folder\Assembly1.dll".
En raison de cette variation de nom de chemin, l'assembly n'a pas pu être récupéré à partir de son chemin d'origine et génère par conséquent l'erreur "Métadonnées non trouvées".
La solution est dans la question de débordement de pile Comment remplacer tous les espaces par% 20 en C #?.
J'avais affronté le même problème. Dans mon cas, j'avais fait référence à un projet de bibliothèque de classes avec une version .Net supérieure à celle de mon projet et VS n'a pas réussi à construire le projet et a généré la même erreur que vous avez signalée.
Je mets simplement la version .Net de mon projet de bibliothèque de classes (celui qui a cassé la construction) de manière identique à la version .Net du projet référencé et du problème résolu.
Dans mon cas, le problème était que j'avais supprimé manuellement un fichier non compilé qui était marqué comme "manquant". Une fois que j'ai supprimé la référence au fichier maintenant manquant et recompilé - tout allait bien.
Pour en revenir à cela quelques années plus tard, ce problème est probablement lié à la limite de chemin maximale de Windows:
Nommer des fichiers, des chemins et des espaces de noms, Limitation de la longueur maximale du chemin
Il semble que ce type d’erreurs soit dû au fait que Visual Studio ne fournit pas d’informations correctes sur une erreur. Le développeur ne comprend même pas la raison de l'échec de la construction. Cela peut être une erreur de syntaxe ou autre chose. En règle générale, pour résoudre de tels problèmes, vous devez en trouver la racine (par exemple, consultez le journal de construction).
Dans mon cas, le problème était en fait que la fenêtre Error List ne montrait aucune erreur. Mais il y avait vraiment des erreurs de syntaxe; J'ai trouvé ces erreurs dans la fenêtre Output et, après les avoir corrigées, le problème a été résolu.
Cette erreur peut être affichée si vous utilisez de faux assemblages. La suppression des contrefaçons permet une construction réussie du projet.
J'utilise Visual Studio 2013.
Il semble que les dépendances de construction étaient incorrectes. La suppression des fichiers * .suo a résolu les problèmes que je rencontrais.
Dans mon cas, c’était que j’avais commenté des classes dans un espace de noms spécifique (vide):
namespace X.Y.Z.W
{
// Class code
}
Lorsque j'ai supprimé le code d'espace de nom et les commandes d'importation (d'utilisation) de celui-ci, le problème a été résolu.
Dans la construction, il était également indiqué - avec le fichier manquant DLL du projet:
erreur CS0234: Le type ou le nom d'espace de noms 'W' n'existe pas dans l'espace de noms 'X.Y.Z' (il manque une référence d'assembly?)
J'ai eu cette erreur lorsque j'essayais de publier une application Web. Il s'est avéré que l'une des propriétés d'une classe était encapsulée dans
#if DEBUG
public int SomeProperty { get; set; }
#endif
mais l'utilisation de la propriété n'était pas. La publication a été effectuée dans la configuration Release sans le symbole DEBUG, évidemment.
Si vous avez un espace dans le nom de votre solution, cela provoquera également le problème. Supprimer l'espace du nom de votre solution afin que le chemin ne contienne pas% 20 résoudra ce problème
Soulignant simplement l'évidence flagrante: si vous n'avez pas activé l'option "Afficher la fenêtre de sortie au démarrage de la construction", assurez-vous de noter si votre construction échoue (petite erreur "build failed" en bas à gauche) !!!
J'ai reçu cette erreur après l'ouverture d'un projet dans lequel Entity Framework était référencé. J'ai donc supprimé ces références et réinstallé Entity Framework version 6.0.0.0 via pthe acket manager de la manière suivante:
install-package entityframework -version 6.0.0.0
L'erreur apparaissait toujours et j'ai donc pensé que ces références existaient, car une version plus ancienne d'Entity Framework était supposément "préinstallée" sur le projet, mais cela ne fonctionnait pas vraiment.
Je suis donc allé dans le fichier packages.config et j'ai remarqué qu'il y avait une autre référence:
<packages>
**<package id="EntityFramework" version="5.0.0" targetFramework="net45" />**
<package id="EntityFramework" version="6.0.0" targetFramework="net45" />
</packages>
Ensuite, j'ai supprimé la ligne, nettoyé et reconstruit le projet et la solution de conteneur, et tout a finalement fonctionné.
D'après le message d'erreur, je ne crois pas que le chemin du fichier est tronqué. Cela semble juste être incorrect. Si je lis correctement le message, il semble que le fichier DLL se trouve à ...
WORK = -\Tools\VersionManagementSystem\BusinessLogicLayer\bin\Debug\BusinessLogicLayer.dll
Ce n'est pas un chemin valide. Est-il possible que vous ayez une définition de macro dans le processus de construction définie sur une valeur non valide?
Dans mon cas, ces erreurs ont été causées par une corruption dans le gestionnaire de paquets NuGet. Les sous-projets de la solution n'étaient pas générés, mais aucune erreur n'était affichée en raison des erreurs de métadonnées.
Une fois que tous les paquets NuGet ont été corrigés, le projet peut à nouveau être construit correctement.
J'ai eu le même problème. Dans mon cas, le projet continuerait à générer en mode de publication et c’est juste au moment où j’ai essayé de créer dans le débogage qu’il a échoué.
Ce que j'ai finalement fait pour résoudre le problème était simplement de copier toutes les dll (et les autres fichiers de mon dossier de publication) dans mon dossier de débogage. Après avoir fait cela pour chaque projet, les erreurs ont disparu.
Supprimer le dossier packages contenant NuGet dans le dossier de la solution a fonctionné pour moi. Après avoir reconstruit tout fonctionnait à nouveau. Vérifiez References dans la solution et recherchez les références qui ont un triangle jaune.
Exemple d'image:
Dans mon cas, j'ai eu cette erreur car l'un de mes projets utilisait une version du framework .NET différente de celle de la solution. J'ai utilisé le gestionnaire de paquets NuGet pour installer NLog, je pense donc qu'il a été installé pour la version .Net de ce projet.
J'ai essayé toutes les solutions de ce post, mais aucune ne fonctionnait. J'ai enlevé NLog, nettoyé la solution et compilé: Même chose, erreur CS006.
C'est quand j'ai supprimé tous les fichiers dans obj\Debug de ce projet que la solution a été compilée.
J'ai eu un problème similaire lorsque j'ai décompilé une très vieille bibliothèque, qui a été déployée dans un environnement de production, mais le code source a été perdu.
J'ai pris .dll, décompilé et généré des projets et solution. J'ai été incapable de construire la solution en raison de plusieurs erreurs de ce type.
Les astuces des réponses précédentes n’ont pas aidé, mais au bout d’un moment j’ai remarqué des références manquantes dans certains projets à plusieurs assemblys comme System.dll.
Supposons qu'il y ait un projet A dépendant du projet B. Il n'y avait aucune référence à System.dll dans le projet B, mais l'erreur après la compilation était du type "Le fichier de métadonnées 'B.dll' est introuvable".
Il n'y avait aucune erreur à propos de System.dll manquant dans le projet B.
L'ajout de références à des bibliothèques telles que System.dll dans le projet B a résolu le problème . (System.Data, System.DirectoryServices, etc.)
J'ai eu une classe dans 4.6.1 référence une interface qui était dans 4.6.2 ... mise à niveau de la classe à 462 corrigée.
Dans mon cas, certains projets de la solution étaient destinés à Tout processeur , certains à x86. L'erreur de compilation a disparu après l'unification de la cible de la plateforme dans la solution.
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 a provoqué l’erreur pour moi.
Dans mon cas, c’était ReSharper être idiot et, même si mon projet visait le C 6, on me proposait de refactoriser pour utiliser des fonctionnalités en C 7 uniquement.
Pour cette raison, j'ai fini par changer ce code,
private DateTime? _joinedDate;
[Column(TypeName = "DateTime2")]
public DateTime JoinedDate
{
get { return _joinedDate ?? DateTime.Now; }
set { _joinedDate = value; }
}
dans ce code:
private DateTime? _joinedDate;
[Column(TypeName = "DateTime2")]
public DateTime JoinedDate
{
get => _joinedDate ?? DateTime.Now;
set => _joinedDate = value;
}
Pour une raison quelconque, le getter et le configurateur utilisant des corps d'expression ont amené le compilateur à afficher cette erreur de métadonnée au lieu d'une erreur de syntaxe.
J'ai eu ce problème parce que .nuget\NuGet.exe n'était pas inclus dans mon référentiel. Bien que j'ai activé DownloadNuGetExe dans NuGet.targets, une erreur de proxy a été signalée lors de la tentative de téléchargement. Cela a entraîné l'échec du reste des constructions du projet.
aaaaa et six ans plus tard, lors d’une mise à niveau vers Visual Studio 2015, le même problème. Parce que cette solution particulière ne figure pas dans cette liste, j'y ajoute des éléments.
Deux dll référencées se trouvaient dans le dossier c:\windows\system32 ... . Leur déplacement dans un dossier non système et l'ajout d'une référence au nouveau dossier ont finalement résolu le problème. Le reste des questions était en effet ce que d’autres ont déjà dit ici
La cause du problème peut être que vous avez mélangé l'ajout de références à des fichiers DLL et des projets dans la solution.
Si vous avez des projets A, B et C:
- A référence B et C en tant que projets dans la solution.
- B fait référence à C en tant que fichier DLL (référence à un fichier)
Vous pouvez construire chaque projet séparément, mais vous ne pouvez pas reconstruire une solution se terminant par: Le fichier de métadonnées «C.dll» est introuvable.
Changer la référence d'un fichier à un projet dans la solution aide.
Comme l'utilisateur @burzhuy le souligne, il peut être important de regarder la fenêtre Output, et pas seulement la fenêtre Error List.
Dans mon cas, je travaillais à apporter des modifications au compilateur Roslyn . Ses projets de construction exécutent une vérification supplémentaire pour voir si les champs publics sont compatibles avec ce qui a été défini comme interface publique du compilateur. Sinon, une erreur RS0016 ou RS0017 est générée. J'avais ajouté quelques champs publics et corrigé l'erreur RS0016 en survolant l'erreur avec la souris et en sélectionnant "Ajouter à l'API publique".
Plus tard, j'ai changé d'avis et déplacé les champs publics dans une classe différente. Pour une raison quelconque, cela a généré le "erreur de fichier de métadonnées introuvable", et plus je le manipulais, plus j'ai d'erreurs.
Vous devez trouver le fichier PublicAPI.Unshipped.txt correct (dans mon cas, il était dans E:\Roslyn\32414\src\Compilers\Core\Portable) et le modifier manuellement pour supprimer les lignes qui ne sont plus pertinentes.
Dans mon cas, j'ai reçu ce message d'erreur pour la simple raison que, après avoir obtenu la dernière version du projet auprès de TFS, le mauvais projet dans la solution était marqué comme projet de démarrage. Choisir le bon projet en tant que projet de démarrage a résolu le problème pour moi.
Wow, il semble que cette erreur puisse venir de partout.
Quoi qu'il en soit, j'ai ajouté un nouveau contrôleur WebAPI à mon application MVC et il a obtenu automatiquement toutes les références de NuGet. Peu de temps après, j'ai supprimé les références de l'interface utilisateur de NuGet, mais j'ai oublié de supprimer les fichiers les utilisant (c'est-à-dire System.Http).
Pour une raison quelconque, l'erreur que je recevais était la suivante, avec un simple avertissement à propos d'une variable non utilisée.
J'ai commenté la variable pour me débarrasser au moins de l'avertissement et la reconstruction m'a indiqué tous les fichiers qui utilisaient la référence non existante. Après avoir supprimé ces fichiers, tout s'est bien passé.
J'ai fait face à ce problème. Dans mon cas, plusieurs projets C # ont été référencés en tant que fichiers DLL. Toute erreur de compilation dans un projet utilisé en tant que fichier DLL (dans d'autres projets) entraînerait une série d'erreurs. La raison en est que l'erreur de compilation empêche la création du fichier DLL correspondant, ce qui entraîne une série d'erreurs dans les projets qui font référence au fichier DLL manquant.
Par conséquent, lorsque vous reconstruisez dans l'Explorateur de solutions (en ignorant les erreurs triviales de compilation), une série d'erreurs "fichier de métadonnées .dll n'a pas été trouvé" se produira (ce qui vous fera penser à quel tort vous avez fait autrement qu'une simple reconstruction).
Si vous rencontrez ce problème, la meilleure solution consiste à nettoyer la solution, puis à construire chaque projet un par un pour déterminer le projet à l'origine de l'erreur.
Ce problème peut être dû à une erreur de syntaxe dans votre code qui pourrait ne pas être visible à cause de l'erreur de métadonnées. Vérifiez donc votre fichier source avant d’effectuer l’une des actions décrites précédemment.
J'ai découvert que si vous supprimez Microsoft.CSharp Assembly comme référence dans le projet, vous obtiendrez cette erreur.
Mon problème est arrivé quand j'ai écrit le code c # 7 mais que le projet utilisait une version plus ancienne du framework .net
J'ai rencontré cette erreur avec Visual Studio 2015 lorsque j'ai supprimé l'annotation de type d'un appel à une méthode d'extension, ce qui ne laissait que les chevrons vides.
Donc, au lieu de obj.extensionMethod<Type>(), j’ai eu obj.extensionMethod<>().
Je classerais ceci comme un bogue dans Visual Studio puisque je ne vois pas comment cette erreur pourrait produire cette erreur.
Pour moi, le problème était que j'avais deux fenêtres Visual Studio ouvertes, mon projet s'exécutait dans le débogage dans une fenêtre et j'ai essayé de le construire dans une autre.
Je devais arrêter le débogage et cela me permettait de construire avec succès.
Je suis d'accord que tout ce qui précède est juste une différence. Dans mon cas, j'utilise Visual Studio 2019. J'ai fermé le VS-2019 et ouvert avec le VS-2017. et reconstruire le projet tout fonctionne bien! Pour qui dans mon poste la date est: 19/04/2019
- Faites un clic droit sur la solution et cliquez sur Nettoyer.
- Cliquez avec le bouton droit sur la solution, puis sur Reconstruire.
Dans mon cas, j'ai résolu ce problème après avoir constaté que j'avais référencé un projet .Net Framework 4.7 en tant que dépendance d'un projet .Net Framework 4.6.1. Après la migration du projet 4.7 vers 4.6.1, mon application est compilée normalement
Vérifiez le fichier .csproj du projet principal. Visual Studio ne le nettoie pas si vous supprimez des projets ou modifiez des références dans la solution.
J'avais d'anciens projets référencés trois fois dans le fichier .csproj et la compilation a montré cette erreur aux projets supprimés.
J'ai vu cette erreur parce que j'avais la ligne suivante dans mon code (on dirait que je pensais encore en mode SQL):
if(myVar is null)
DoSomething();
Visual studio (2017) n'a signalé aucune erreur lors de la conception ou de la compilation, mais le projet n'a pas été généré et a généré l'erreur ".dll manquant". En changeant la ligne erronée en:
if(myVar == null)
Le problème était résolu.
Dans mon cas, j'ai eu aussi beaucoup d'autres erreurs de compilation (quelques conversions de types simples), je me suis égratigné pour essayer de résoudre ce problème et je ne me suis pas concentré sur les autres erreurs.
Ce qui a finalement résolu mon problème, c’est que j’ai corrigé toutes les autres erreurs de construction, puis que je compile à nouveau et que la construction soit réussie.
Donc, si vous avez d'autres erreurs de construction avec une erreur de fichier manquante DLL, et que rien d'autre ne fonctionne pour vous, essayez de réparer les autres erreurs en premier, puis générez à nouveau la solution.
Aucune des dizaines de réponses à ce jour n'a fonctionné pour moi. Dans mon cas, j'ai aussi eu l'erreur:
Le nom de l'élément de tuples 'Valeur' est inféré. Veuillez utiliser la version 7.1 ou supérieure du langage pour accéder à un élément par son nom inféré.
Ceci est apparu à côté de "erreurs de fichier de métadonnées '.dll' lors de la construction, mais il a disparu peu de temps après, comme le font parfois les erreurs lorsque le IDE" rattrape ".
Double-cliquez sur l'erreur pour la trouver et supprimez le code incriminé pour la corriger.
Sinon, vous pouvez essayer ceci dans Visual Studio:
Menu Projet → <Nom du projet> Propriétés → Construire → Bouton Avancé → Version linguistique → C # <dernière version mineure> (par exemple, " C # 5.0 ")
Et cela corrige aussi.
Il semble que "Le fichier de métadonnées '.dll' est introuvable" est souvent le symptôme de certains problèmes sous-jacents. Si aucune des solutions ne fonctionne pour vous, vérifiez les autres erreurs et avertissements et essayez de trouver le véritable problème.
J'ai eu le même problème et une autre solution.
Le problème: Une solution, plusieurs projets. L'application principale qui utilise certains des autres résultats a échoué en disant:
CSC: erreur CS0006: le fichier de métadonnées 'C:\Repos\TheApplicationCommon\bin\Debug\TheApplication.dll' est introuvable
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ée sans faille.
Avant, j'avais mis à jour un package NuGet interne qui utilisait PostSharp 3.x.x.x et utilise maintenant PostSharp 4.x.x.x. Et ma solution a été d’ajouter ceci à mon fichier * .csproj:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="...">
<Import Project="..." Condition="..." />
<PropertyGroup>
...
<AssemblyName>TheApplication</AssemblyName>
...
<SkipPostSharp>True</SkipPostSharp> <!-- This line -->
</PropertyGroup>
...
Une autre solution-> Nettoyer, une autre solution-> Reconstruire et cela fonctionne localement et sur le serveur de compilation.
J'espère que ça aide quelqu'un. Le fil est ancien et assez long, mais ce problème revient souvent et je n’ai pas encore vu cette solution. Btw utilisant Visual Studio 2017 (15.8.x).
Supprimer les dossiers bin/obj puis reconstruire le projet a fonctionné pour moi.
Dans mon cas, je pense que ce qui s’est passé est que j’ai rencontré une erreur d’exécution la première fois que j’ai construit le projet, de sorte que mon fichier dll n’a pas été généré.
Cela s'est produit lors du référencement d'un projet d'un autre. Le projet auquel je faisais référence était celui avec le problème.
Beaucoup de ces réponses ressemblent à des essais et à des erreurs. Dans mon cas cependant, c’était simple: la dll référencée n’a pas été trouvée à cet endroit particulier.
Si vous voyez les erreurs de génération, généralement dans ce cas, la génération se plaint de nombreuses dll. La clé est de trouver la bonne DLL qui manque. Dans mon cas, l’un des projets de ma solution avait une référence directe à la DLL au lieu d’une référence de projet. J'ai donc dû créer le projet qui génère cette dll avant de générer la solution défaillante afin de m'assurer que celle-ci trouve la dll manquante à cet emplacement particulier.
Wow .. c'était simple, mais assez difficile à décrire.
Dans mon cas, dans mon fichier Web.config, cela change
<?xml version="1.0" encoding="utf-8"?>
pour ça
<?xml version="1.0"?>
résolu mon problème
Dans mon cas, cela m’est arrivé lorsque je faisais référence localement aux paquets NuGet et que je déplaçais leur répertoire ailleurs. J’ai changé le chemin dans NuGet.Config, mais j’ai malheureusement découvert que je devais modifier manuellement les fichiers .csproject pour mettre à jour le chemin de référence. CS0006 était bien loin de décrire ce problème. Généralement, cela se produit également quand il y a une référence à DLL introuvable. Afin de pouvoir identifier le problème, recherchez vos références dans le projet présentant le problème, vous trouverez quelques références avec une icône d'avertissement qui leur est associée. , essayez de les réparer et cela devrait fonctionner comme prévu.
J'ai rencontré ce problème après getting latest (commande Team Foundation Server (TFS)).
Après avoir résolu les conflits, j'ai trouvé une déclaration pour namespace that does not exist in the project.
J'ai donc supprimé cette instruction using puis clean and rebuild et tout s'est bien passé.
Quand je construisais, cela montrait généralement des erreurs comme celle-ci dans Visual Studio 2017:
Error CS0006 Metadata file 'C:\src\ProjectDir\MyApp\bin\x64\Debug\Inspection.exe' could not be found MyApp C:\src\ProjectDir\MyApp\CSC 1 Active
Mais parfois, une erreur comme celle-ci s’affiche pendant quelques secondes, puis disparaît pour revenir au message ci-dessus:
Error CS1503 Argument 1: cannot convert from 'MyApp.Model.Entities.Asset' to 'MyApp.Model.Model.Entities.Inspection' MyApp C:\src\ProjectDir\MyApp\ViewModels\AssetDetailsViewModel.cs 1453 Active
J'ai donc passé du temps à résoudre la première erreur, mais le problème réel s'est avéré être dû à la seconde erreur. J'ai d'abord dû supprimer tous les répertoires/bin et/obj, puis j'ai également supprimé les fichiers .suo comme indiqué ci-dessus. Cela m'a permis de réduire le problème à un problème d'interface.
J'ai eu ceci dans mon interface:
Task<IList<Defect>> LoadDefects(Asset asset);
Mais dans ma mise en œuvre actuelle, j'avais ce code:
public virtual async Task<IList<Defect>> LoadDefects(Inspection inspection)
{
var results ...
// ....
return results;
}
La construction s'est terminée avec succès après la mise à jour de l'interface:
Task<IList<Defect>> LoadDefects(Inspection inspection);
Il semble donc que la mise en cache dans VS l’a forcée à afficher l’erreur CS0006 alors que le problème était l’erreur CS1503.
Aucune des solutions précédentes n'a fonctionné pour moi, donc je vais partager ce qui a fonctionné.
J'ai eu ce problème après avoir fusionné de nouvelles bibliothèques de classes d'une autre branche qui se référaient les unes aux autres. La suppression des références dans les projets et leur recréation ont finalement résolu le problème. Apparemment, Visual Studio avait fusionné sur de mauvais chemins de fichiers.
Pour moi, le problème était une erreur qui n’était pas apparue dans la sortie de la construction, c’est-à-dire que j’avais deux classes d’utilitaires qui étaient initialement dans des espaces de noms différents. J'ai changé l'espace de noms du second pour le faire correspondre au premier (sans savoir qu'il y avait une autre classe d'utilitaires dans la première), et c'est à ce moment-là que cette erreur a commencé à se produire.
J'imagine que l'erreur de sortie de la génération a fait surface, car le fichier DLL de la bibliothèque de couches logiques n'a pas pu être créé et l'application principale ne l'a pas trouvé.
La solution consistait à reconvertir la deuxième classe d'utilitaires en un espace de noms différent et c'est à ce moment-là que les vraies erreurs de construction ont commencé à affluer. Après les avoir triées, la construction s'est bien déroulée.
En guise d'aperçu, si l'une des solutions précédentes ne vous convient pas, les erreurs que le code n'affiche pas dans Visual Studio ont peut-être été supprimées. Essayez donc de retracer vos étapes de codage et de rechercher d'éventuelles irrégularités.
PS: c'était dans Visual Studio 2015 Community Edition
J'ai commencé à avoir ce problème après avoir beaucoup changé de solution, en rangeant les changements et en les annulant.
Le seul moyen de le résoudre consistait à supprimer et à ajouter à nouveau le mappage de TFS dans mon dossier local.
Ce problème peut survenir car vous utilisez des fonctionnalités qui ne sont pas prises en charge par la version de . Net sélectionnée pour le projet.
Dans mon cas, la raison est que j’ai utilisé l’opérateur ?? pour rechercher les exceptions null et throw.
C'est assez étrange que VS n'informe pas de la raison réelle du problème dans la liste des erreurs de construction.
Mais vous pouvez trouver cette information dans les journaux Output de la construction.
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:
- Fichier .dll manquant
- Méthode déjà définie à un autre endroit avec les mêmes paramètres
J'ai effacé la deuxième erreur d'abord en supprimant la fonction qui a été dupliquée à un autre endroit.
Ma première erreur - c’est le fichier .dll manquant, l’a résolu elle-même.
Je veux dire, si vous avez plus d'une erreur avec l'erreur de fichier manquant .dll, veuillez essayer de résoudre les autres erreurs en premier. Peut-être que l'erreur .dll le résout elle-même!
Dans mon cas, la définition du cadre cible a résolu le problème:
Faites un clic droit sur le projet et sélectionnez Propriétés
Dans Application , changez Cadre cible pour qu'il soit identique au projet principal (par exemple, ".NET Framework 4.5").
Visual Studio IDE n'effectue aucune construction en arrière-plan, mais l'application Msbuild. Le VS IDE construit essentiellement le fichier de projet utilisé par Msbuild et, bien souvent, il commet des erreurs si vous laissez le soin à IDE de déterminer seul le fichier. Si vous obtenez l'erreur Metadata file '.dll' could not be found, cela est probablement dû au fait que les assemblys corrects/attendus ne sont pas trouvés. Donc, Visual Studio crée peut-être un fichier de projet pour une application Framework 4.5 et attend des assemblys 4,5 alors que vous faites référence à des assemblys 4.0. Vérifiez les incompatibilités de vos paramètres Visual Studio ou entrez vous-même dans le fichier de projet et corrigez-le manuellement en spécifiant le chemin correct <Reference Include="C:\\correct path to Assembly\\yourAssembly.dll" />.