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 référence mes contrôles utilisateur:

xmlns:vms="clr-namespace:VersionManagementSystem"
<vms:SignOffProjectListing Margin="5"/>

Cela se produit après chaque build échoué. La seule façon dont je peux obtenir la solution à compiler est de commenter tous mes contrôles utilisateur et de recréer le projet, puis je décommente les contrôles utilisateur et tout va bien.

J'ai vérifié les ordres de génération et les configurations des dépendances.

Comme vous pouvez le voir, il semble avoir tronqué le chemin absolu du fichier DLL ... J'ai lu qu'il y a un bug avec la longueur. Est-ce un problème possible?

C'est très ennuyeux et avoir à commenter, construire et décommenter, la construction devient extrêmement fatigante.

J'ai juste eu le même problème. Visual Studio ne construit pas le projet référencé.

Instructions écrites:

1. Cliquez avec le bouton droit sur la solution et cliquez sur Propriétés.
2. Cliquez sur Configuration à gauche.
3. Assurez-vous que la case sous "Build" pour le projet qu'il ne trouve pas est cochée. Si elle est déjà cochée, décochez-la, appuyez sur Appliquer et cochez à nouveau les cases.
4. (Facultatif) Vous deviez le faire pour les modes Release et Debug sur les propriétés de la solution.

Instructions de capture d'écran:

• Ils disent qu'une image vaut mille mots. Cliquez sur le GIF pour zoomer, et j'espère que ce sera facile à suivre:

Cela peut toujours se produire dans les versions plus récentes de Visual Studio (je viens de le faire sur Visual Studio 2013):

Une autre chose à essayer est de fermer Visual Studio et de supprimer le .suofichier à côté du .slnfichier. (Il sera recréé la prochaine fois que vous Save all(ou quitterez Visual Studio)).

J'ai eu ce problème lors de l'ajout de nouveaux projets à la solution sur une autre machine, puis lors de l'extraction des révisions, mais le .suofichier peut également être corrompu dans d'autres cas et conduire à un comportement très étrange de Visual Studio, donc le supprimer est l'un des des choses que j'essaie toujours.

Notez que la suppression du .suofichier réinitialisera le ou les projets de démarrage de la solution.

Plus d'informations sur le .suofichier 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 un avertissement par le compilateur, mais cela entraînait l'échec de la construction. Cela aurait dû être signalé comme une erreur et non comme un avertissement.

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

Section 1):

En solutions générales:

J'ai eu quatre erreurs de ce type («le fichier de métadonnées est introuvable») ainsi qu'une 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 «Le fichier de métadonnées est 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 Visual Studio et essayez à nouveau de générer.

2. Allez dans «Explorateur de solutions» . Faites un clic droit sur Solution. Allez dans Propriétés . Accédez à «Configuration Manager» . Vérifiez si les cases à cocher sous «Build» sont cochées ou non. Si certains ou tous ne sont pas cochés, vérifiez-les et réessayez de les 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 réessayez de construire.

4. Créer des dépendances d'ordre et de projet:

   Allez dans «Explorateur de solutions» . Faites un clic droit sur 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 se construit. Vérifiez les dépendances du projet et l'ordre de génération pour vérifier si un projet (par exemple «projet1») qui dépend d'un autre (par exemple «projet2») essaie de créer avant celui-ci (projet2). Cela pourrait être la cause de l'erreur.

5. Vérifiez le chemin d'accès du fichier .dll manquant:

   Vérifiez le chemin d'accès du fichier .dll manquant. Si le chemin contient de l'espace ou tout autre caractère de chemin non valide, supprimez-le et essayez à nouveau de construire.

   Si c'est la cause, ajustez l'ordre de génération.

Section 2):

Mon cas particulier:

J'ai essayé toutes les étapes ci-dessus avec diverses permutations et combinaisons avec le redémarrage de Visual Studio plusieurs fois. Mais cela ne m'a pas aidé.

J'ai donc décidé de me débarrasser des autres erreurs que je rencontrais ('Le fichier source n'a pas pu être ouvert (' 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 «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 est introuvable») comme bien.

Section 3):

Morale de l'histoire:

Essayez toutes les solutions mentionnées dans la section (1) ci-dessus (et toutes les autres solutions) pour vous débarrasser de 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 de source et le système de fichiers de votre fichier .csproj .

Dans mon cas, cela a été causé par une incompatibilité de version de .NET Framework.

Un projet était 3.5 et l'autre projet de référencement 4.6.1.

La fermeture et la réouverture de Visual Studio 2013 ont fonctionné pour moi!

Eh bien, rien dans les réponses précédentes n'a fonctionné pour moi, donc cela m'a fait penser à pourquoi je clique et j'espère quand en tant que développeurs nous devrions vraiment essayer de comprendre ce qui se passe ici.

Il m'a semblé évident que cette référence incorrecte de fichier de métadonnées doit être conservée quelque part.

Une recherche rapide du fichier .csproj a montré les lignes coupables. J'avais une section appelée <itemGroup> qui semblait s'accrocher à 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:

1. Sauvegardez votre fichier .csproj.
2. Recherchez les chemins d'accès incorrects dans le fichier .csproj et renommez-les de manière appropriée.

Veuillez vous assurer de sauvegarder votre ancien .csproj avant de jouer du violon .

J'ai également rencontré ce problème. Tout d'abord, vous devez créer manuellement votre projet DLL, par un clic droit sur Build. Ensuite, cela fonctionnera.

Dans mon cas, j'ai mon répertoire installé de manière erronée.

Si le chemin de votre solution est quelque chose comme "Mon projet% 2c Test de l'unité% 2c très populaire% 2c Software and Hardware.zip", il ne peut pas résoudre le fichier de métadonnées, nous devrions peut-être empêcher certains mots invalides comme% 2c.

Renommer le chemin en nom normal a résolu mon problème.

J'ai reçu 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 à un fichier DLL tiers qui ciblait une 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.

Visual Studio 2019, cela a fonctionné pour moi:

1. Fermez Visual Studio
2. Supprimer le .vsdossier caché
3. Rouvrez Visual Studio et reconstruisez la solution.

Pour moi, il essayait de trouver une DLL dans un chemin qui contenait le projet, mais nous l'avions déplacé vers un nouveau répertoire. La solution avait le chemin d'accès correct au projet, mais Visual Studio continuait en quelque sorte à rechercher dans l'ancien emplacement.

Solution: Renommez chaque projet problématique - ajoutez simplement un caractère ou autre - puis renommez-le en son nom d'origine.

Cela doit réinitialiser un cache global quelconque dans Visual Studio, car cela efface à la fois ce problème et plusieurs autres, alors que des choses comme Clean ne le font pas.

J'ai ajouté un nouveau projet à ma solution et j'ai commencé à l'obtenir.

La raison? Le projet que j'ai apporté visait un framework .NET différent (4.6 et mes deux autres étaient 4.5.2).

Pour moi, cela s'est produit lorsque j'ai inclus un nouveau projet dans 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é.

Pour moi, les étapes suivantes ont fonctionné:

• Trouvez le projet qui ne se construit pas
• Supprimez / ajoutez des références à des projets dans la solution.

Je tirais 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 était d'ouvrir chaque projet dans ma solution 1 par 1 et de les construire individuellement.

Ensuite, j'ai fermé Visual Studio 2013, rouvert ma solution et elle s'est bien compilée.

C'est étrange, car si j'ai cliqué sur chaque projet dans mon Explorateur de solutions et essayé de les construire de cette façon, ils ont tous échoué. J'ai dû les ouvrir seuls dans leurs propres solutions.

Il ressemble à ce type d'erreurs liées 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 trouver la racine du problème (par exemple, consultez le journal de génération).

Dans mon cas, le problème était en fait que la Error Listfenêtre ne montrait aucune erreur. Mais il y avait vraiment des erreurs de syntaxe; J'ai trouvé ces erreurs dans la Outputfenêtre et après les avoir corrigées, le problème a été résolu.

Mon instance du problème a été causée par un projet commun qui avait un nom de classe en double (sous un nom de fichier différent). Il est étrange que Visual Studio ne puisse pas détecter cela et ait simplement fait exploser le processus de génération.

J'ai eu ce problème dans Visual Studio 2012 dans une solution qui avait 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) l'a corrigé pour moi.

Finalement, je suis arrivé à celui qui m'a donné une erreur de compilation. J'ai corrigé l'erreur et la solution se construirait correctement après cela.

Dans mon cas, le problème était que j'avais supprimé manuellement un fichier de non-compilation qui était marqué comme "manquant". Une fois que j'ai supprimé la référence au fichier manquant et recompilé - tout allait bien.

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.

Pour y revenir quelques années plus tard, ce problème est probablement lié à la limite de chemin d'accès maximale de Windows:

Nommage des fichiers, des chemins et des espaces de noms , limitation de la longueur maximale du chemin

Dans mon cas, le problème était dû à une simple erreur de construction,

erreur CS0067: l'événement 'XYZ' n'est jamais utilisé

qui, pour une raison quelconque, n'apparaissait pas dans la fenêtre d'erreur.

À cause de cela, le système de génération de Visual Studio a semblé manquer l'erreur et a tenté de créer des projets dépendants, qui à leur tour ont échoué avec le message de métadonnées ennuyeux.

La recommandation est aussi stupide que cela puisse paraître:

Regardez d'abord votre fenêtre de sortie !

Il m'a fallu une demi-heure avant que cette idée ne me frappe ...

Moi aussi, j'ai eu la même erreur. Il se cache comme dans le chemin ci-dessous. Le chemin d'accès auquel j'ai fait référence pour le fichier DLL est comme "D: \ Assemblies Folder \ Assembly1.dll".

Mais le chemin d'origine dans lequel l'assembly fait référence é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 donc l'erreur «Métadonnées non trouvées».

La solution se trouve dans la question Stack Overflow Comment remplacer tous les espaces par% 20 en C #? .

J'avais fait face au 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 à mon projet et VS n'a pas réussi à générer le projet et a soulevé la même erreur que vous avez publiée.

J'ai simplement défini la version .Net de mon projet de bibliothèque de classes (celui qui avait cassé la construction) identique à la version .Net du projet référencé et le problème a été résolu.

Juste en soulignant l'évidence: si vous n'avez pas activé "Afficher la fenêtre de sortie lorsque la construction démarre", assurez-vous de remarquer si votre génération échoue (petite erreur "échec de la construction" en bas à gauche) !!!!

J'ai rencontré 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 enveloppée dans

#if DEBUG
    public int SomeProperty { get; set; }
#endif

mais l'utilisation de la propriété ne l'était pas. La publication s'est faite en configuration Release sans le DEBUGsymbole, évidemment.

Sur la base du message d'erreur, je ne pense pas que le chemin d'accès au fichier soit tronqué. Cela semble juste incorrect. Si je lis correctement le message, il semble rechercher le fichier DLL à ...

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?

J'ai eu ce problème car il .nuget\NuGet.exen'était pas inclus dans mon référentiel. Bien que j'aie activé DownloadNuGetExedans NuGet.targets, il a signalé une erreur de proxy lors de la tentative de téléchargement. Cela a provoqué l'échec du reste des versions du projet.

Cette erreur peut s'afficher si vous utilisez de faux assemblys. La suppression des contrefaçons conduit à la réussite de la construction du projet.