Erreur "Le fichier de métadonnées '...\Version\project.dll' est introuvable dans Visual Studio"
Récemment, j'ai commencé à recevoir ce message au hasard:
Le fichier de métadonnées '...\Release\project.dll' est introuvable dans Visual Studio
J'ai une solution avec plusieurs projets. Le mode de construction actuel est Debug et toutes les configurations de projets sont définies sur Debug. Mais lorsque j'essaie d'exécuter le projet principal - parfois, il génère quelques erreurs, qui sont toutes "le fichier de métadonnées '...\Release\projectX.dll' est introuvable" - et regardez, il est écrit à propos de RELEASE dossier, bien que le mode actuel soit Debug. Pourquoi? J'ai essayé de rechercher la référence à "Release\projectX.dll" dans tous les fichiers de solution et j'en ai trouvé un dans le fichier ResolveAssemblyReference.cache.
J'ai fait une bonne recherche sur Internet et j'ai trouvé quelques personnes avec un problème similaire, mais il n'y avait pas de solution, ou du moins aucune solution efficace.
J'ai essayé de supprimer les références à ces projets et de les lire, mais à un moment donné, je recommence à avoir ces erreurs.
Cela ressemble à un bug. Pourquoi recherche-t-il les projets référencés dans les dossiers de publication lorsque j'utilise toujours le mode débogage?
PS. Pour ceux qui ont rencontré ce problème: je ne pouvais pas le résoudre facilement. Il a disparu seulement après avoir réinstallé Windows :(
Tout le monde est correct ... essayez tout ... (dans l'ordre de perdre beaucoup de temps)
- Avez-vous un mauvais code? Résoudre cela en premier.
- Nettoyer la solution et redémarrer Visual Studio
- Supprimer/Ajouter des références
- Vérifiez votre ordre de construction avec des projets plus importants et vérifiez
- Reconstruire manuellement des sous-projets
- Copier manuellement les dll entre les projets dans les dossiers bin associés
- Allez prendre un café, jouez au flipper et revenez demain ... vous pouvez penser à autre chose en attendant.
J'ai eu exactement le même problème. Grande solution de studio visuel avec plus de 50 projets.
Toutes les références ont été ajoutées en tant que projets. L’ordre de construction du projet était correct (cliquez avec le bouton droit sur le projet et sélectionnez l’ordre de construction).
Cependant, lors de la construction de certains projets de niveau supérieur, le projet "racine" sur lequel ils dépendaient n'a pas été construit.
Le problème était que ces projets n'avaient pas été sélectionnés pour la construction dans la configuration actuelle (je ne sais pas comment cela s'est passé).
Pour vérifier cela, sélectionnez "Configuration Manager" (menu Build) et vérifiez si les projets problématiques sont configurés pour construire.
Quand vous dites que vous avez supprimé les références à ces projets et les avoir rajoutées, comment les avez-vous rajoutées exactement? Avez-vous utilisé l'onglet "Parcourir" dans la boîte de dialogue "Ajouter une référence" de Visual Studio? Ou avez-vous utilisé l'onglet "Projets" (qui répertorie les projets voisins dans votre solution)?
Edit : Si vous utilisez l'onglet "Parcourir" et ajoutez manuellement la référence à votre .dll située dans le dossier/Release, Visual Studio recherchera toujours le fichier .dll à cet emplacement, quel que soit le résultat. mode dans lequel vous êtes actuellement (débogage ou libération).
Si vous avez supprimé le fichier .dll actuel du dossier de publication (manuellement ou avec l'option "Nettoyer la solution"), votre référence sera rompue car le fichier .dll n'existe pas.
Je suggère de supprimer la référence à ProjectX.dll et de l'ajouter à nouveau - mais cette fois-ci, utilisez l'onglet "Projets" de la boîte de dialogue "Ajouter une référence". Lorsque vous ajoutez une référence de cette manière, Visual Studio sait où obtenir le fichier .dll approprié. Si vous êtes en mode débogage, il sera obtenu à partir du dossier/Debug. Si vous êtes en mode Release, le dossier/Release. Votre erreur de génération devrait disparaître et vous ne ferez plus non plus (de manière incorrecte) une référence à un fichier Release .dll en mode débogage.
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 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 j’ai trouvé que ces solutions pouvaient être efficaces (en les résumant ici):
Redémarrez VS 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 construire à nouveau.
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 VS plusieurs fois. 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 blog: http://www.anujvarma.com/tfs-errorsource-file-could-not-be-be-opened-unspecified-error/#comment-1539
J'ai essayé les étapes mentionnées dans ce blog et je me suis débarrassé de l'erreur 'Impossible d'ouvrir le fichier source (' erreur non spécifiée ')' et étonnamment je me suis débarrassé d'autres erreurs (le fichier de métadonnées ne pouvait pas 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}
J'ai déjà eu ce problème auparavant et la seule solution que j'ai trouvée pour le résoudre consiste à exécuter Clean Solution, puis à redémarrer Visual Studio.
Pour moi, c'est généralement le framework cible qui est désactivé (4.5.2 au lieu de 4.6) Si vous corrigez le framework cible du projet pour qu'il corresponde au framework cible de la solution et que vous génériez, un nouveau fichier .dll sera créé.
Rouvrez Visual Studio en tant qu'administrateur.
La plupart des réponses disent que vous devez supprimer les bibliothèques de votre solution, c'est vrai, mais lorsque vous rajoutez les bibliothèques, l'erreur sera à nouveau affichée. Vous devez vérifier si toutes les bibliothèques référencées ont un framework .net compatible avec le framework .net de votre solution. Ensuite, corrigez toutes les erreurs dans votre code et reconstruisez la solution.
Avez-vous vérifié les paramètres du gestionnaire de configuration? Dans la boîte de dialogue de configuration du projet, coin supérieur droit.
Il arrive parfois qu'entre toutes les entrées de version, une entrée de débogage entre . Si c'est le cas, la dépendance automatique créée par le graphe de dépendances de la solution est confuse.
J'ai eu le même problème moi-même.
Visual Studio 2013 m'a seulement dit qu'il ne pouvait pas y faire référence et qu'il ne pouvait pas trouver les métadonnées. Lorsque j'ai ouvert ma solution (qui contient plusieurs projets), elle a indiqué que j'utilisais des projets inférieurs à la version-cadre de l'un de mes projets.
J'ai donc tout basculé vers la version 4.5, et cela a encore fonctionné.
Nous avons souvent ce problème, mais uniquement avec des références à des projets C++/CLI à partir de projets C #. Il est évident que Microsoft a décidé de ne pas résoudre le problème, car il est "trop complexe" et a promis une refonte du système de construction C++ désormais ciblé pour Visual Studio 2010.
C'était il y a quelque temps, et peut-être que le correctif a été appliqué à Visual Studio 2008; Je ne l'ai plus suivi. Cependant, notre solution de contournement typique était
- Commutateur de configuration
- Redémarrer Visual Studio
- Construire la solution
Ce problème est dû aux fichiers pdb ou CodeContracts.
Pour le résoudre:
Nettoyez votre dossier de sortie et reconstruisez la solution.
Reconfigurez le CodeContracts ou désactivez-le pour une construction temporaire.
J'ai eu ce problème et j'ai mis longtemps à le comprendre. Un problème est survenu lorsque j'ai retiré des projets de la solution et les ai remplacés par des paquets de pépites.
La solution semblait satisfaisante, mais le fichier .csproj contenait toujours ces projets plusieurs fois à titre de référence.
Il semble que VS ne nettoie pas ce fichier correctement. Il faisait toujours référence aux projets supprimés sous le capot. Lorsque vous supprimez manuellement les références du fichier csproj, tout fonctionne à nouveau! wohoo
Dans mon cas, j'ai eu des erreurs dans mon code. Visual Studio a montré l'erreur que vous aviez à la place des erreurs réelles, telles que des erreurs de syntaxe ou des noms de classes inconnus. Essayez de nettoyer la solution et de construire projet après projet. De cette façon, vous découvrirez les erreurs réelles.
Encore une fois, c’est ce qui cause l’erreur pour moi .
Dans mon cas, cela a été causé par deux choses (VS.2012):
1) L'un des projets a été configuré pour AnyCPU au lieu de x86
2) Un projet référencé avait en quelque sorte la case "Construire" décochée.
Vérifiez votre construction | Configuration Manager pour obtenir un aperçu de ce qui est construit et pour quelle plate-forme. Assurez-vous également de vérifier les paramètres Debug et Release, car ils peuvent avoir des paramètres différents.
Nous avons récemment rencontré ce problème après la mise à niveau vers Office 2010 depuis Office 2007: nous avons dû modifier manuellement les références de notre projet à la version 14 des interconnexions Office utilisées dans certains projets.
J'espère que cela aide - il nous a fallu quelques jours pour le comprendre.
J'ai également constaté cette erreur dans les solutions où j'ai plusieurs projets (généralement des projets netTiers dans lesquels j'ai mis à jour un ou plusieurs des sous-projets afin de cibler le framework 4.0). Cela peut être problématique à enlever. Cependant, il peut souvent être résolu en corrigeant d’abord toutes les autres erreurs dans les sous-projets (par exemple, les références manquantes), en reconstruisant individuellement ces sous-projets, puis en supprimant/rajoutant les références à ces sous-projets dans Visual Studio. Personnellement, j'ai eu peu de chance de résoudre cette erreur en nettoyant la solution seule.
J'ai fini par supprimer mes références (je les avais ajoutées correctement à l'aide de l'onglet Projets et ils construisaient très bien), en modifiant manuellement mes fichiers .csproj et en supprimant les entrées bizarres qui n'appartenaient pas - et en configurant mes sorties pour le release, x86 et x64 et tous les cpu à être "\ bin" - je l’ai construite une fois, puis rajouté la référence (encore une fois, en utilisant l’onglet projets), et tout a recommencé à fonctionner pour moi. Pas besoin de redémarrer Visual Studio du tout.
Il me semble me rappeler avoir eu un problème similaire il y a quelques mois. Je l'ai résolu temporairement en copiant le DLL référencé dans le dossier Release, satisfaisant ainsi les attentes de Visual Studio. Plus tard, j'ai découvert la référence à la version DLL dans mon code actuel. Vous devriez essayer de faire une recherche dans tout le projet pour\release\project.dll.
De plus, j'ai remarqué que les projets de test unitaires Visual Studio ajoutaient parfois un attribut "DeploymentItem" à chacune des méthodes de test pointant vers votre DLL cible. Si vous basculez entre Debug et Release, Visual Studio peut se perdre si la DLL n'est plus à l'emplacement prévu. D'après mon expérience, ces attributs peuvent être supprimés en toute sécurité si vous ne les mettez pas vous-même dans le cadre d'un scénario de "déploiement unique".
Pour moi, cela est dû au fait que la cible Build a été réécrite pour ne pas générer la dll. Supprimer cette option pour revenir à la cible de génération par défaut a résolu le problème.
Parfois, VS2010 bascule ma configuration de n’importe quel processeur vers des plates-formes mixtes. Lorsque cela se produit, je reçois ce message d'erreur.
Pour le résoudre, je retourne à n'importe quel processeur:
1. Cliquez avec le bouton droit sur la solution et sélectionnez Propriétés.
2. Cliquez sur Propriétés de configuration, puis sur le bouton Gestionnaire de configuration ....
3. Sous Plate-forme de solution active, sélectionnez N'importe quel processeur.
Je constate que cela m’arrive généralement lorsque j’ai encore une déclaration de méthode dans une interface, qu’une classe implémente, mais que j’ai ensuite supprimée et que j’avais oublié de la supprimer également. Habituellement, je sauvegarde simplement la solution entière toutes les 30 minutes, puis je reviens à une version antérieure si je ne trouve pas l'erreur.
J'ai eu ce problème et cela était dû à une méthode non valide dans la bibliothèque incriminée (dll) qui ne renvoyait pas de valeur, par exemple.
public bool DoSomething()
{
//I never bothered putting code here....
}
Quand j'ai fait part de tout ça compilé :)
Je rencontrais ce problème lorsque j'essayais d'ajouter une référence à un projet. Après de nombreuses recherches et essais, j'ai constaté que ma configuration et mes sorties étaient correctes.
J'ai finalement finalement supprimé les dossiers\bin et\obj du projet source et du projet de référence.
Honnêtement, je pense que c’était le dossier obj qui ne contenait pas les métadonnées correctes ou des métadonnées corrompues.
Tout est corrigé maintenant.
C'était avec Visual Studio 2015 - Projets 4.6.
METTRE À JOUR:
Ce qui précède fonctionnait avec la première construction, mais échouait avec les versions suivantes. J'ai donc fini par recréer le fichier de solution, puis par supprimer et lire les packages NuGet mal référencés dans mes fichiers de projet, ce qui indiquait le chemin incorrect hint .
Cela semblait l’avoir réglé jusqu’à présent sur les versions ultérieures.
Un exemple de référence dans un fichier .csproj
<ItemGroup>
<Reference Include="Antlr3.Runtime, Version=3.5.0.2, Culture=neutral, PublicKeyToken=eb42632606e9261f, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\..\packages\Antlr.3.5.0.2\lib\Antlr3.Runtime.dll</HintPath>
</Reference>
</ItemGroup>
A eu le même problème aujourd'hui.
Mon application, une application Windows Forms, avait accidentellement une référence à elle-même. Bizarre.
Une fois enlevé, l'erreur est partie.
La référence a été ajoutée chaque fois que j'ai fait glisser un contrôle utilisateur, situé dans le projet Windows Forms lui-même, vers un formulaire.
La ~ 30e réponse :-)
Dans VS2015:
- Faites un clic droit sur la solution
- Sélectionner un ordre de construction de projet
- Consultez la liste des projets dans l'ordre de construction de projet.
- Construisez chacun de vos projets dans cet ordre
- Inspecter la sortie
Dans mon cas, le faire étape par étape a permis de découvrir mon problème sans toutes ces erreurs.
Si vous deviez le savoir, j'ai ajouté Entity Framework (EF) 6.1.3 via NuGet lorsque le projet a été défini pour .NET 4.5.2. J'ai ensuite abaissé le .NET Framework à 4, puis l'erreur était plus évidente. Via NuGet, j'ai désinstallé EF et l'ai ajouté de nouveau.
VÉRIFIEZ VOTRE VOIE DE PROJET. Il ne doit pas y avoir de caractère irrégulier comme une virgule ou un espace
par exemple, ce chemin est incorrect: d:\my applications\Project1
et c'est le vrai chemin d:\my_applications\Project1
Visual Studio ne peut pas construire le projet s'il y a un caractère non alphabétique et numérique dans son chemin sur le disque et qu'aucun message ne s'affiche pour cette erreur!
De plus, certains outils d’installation ont le même problème quand ils commencent l’installation et ne peuvent pas être extraits.
Vérifiez si le dossier .vs dans la racine du projet est masqué ou non. Le mien n'était pas (et il devrait) depuis que j'ai fait un copier/coller d'un autre ordinateur. Le supprimer a résolu le problème, Visual Studio 2015 vient de le recréer pour moi.
J'ai eu le même problème et la raison derrière ce problème est que le fichier DLL du projet de référence est utilisé par un autre processus. Dans mon cas, je déboguais une application et l’application était associée à Visual Studio Debugger. Lorsque je reconstruisais une autre application utilisant le même projet, cette erreur me causait. Après la déconnexion, j'ai pu créer une deuxième application avec succès.
Ce problème a été résolu. J'ai ouvert les paramètres du gestionnaire de paquets et cliqué sur «Autoriser NuGet à télécharger les paquets manquants». Le projet se construit maintenant.
Dans mon cas, lors d'une fusion, il semble que certaines références de projet manquaient dans le fichier de solution. Ré-ajouter manuellement le projet à la solution l'a corrigé. Vous pouvez également modifier manuellement le fichier de solution, mais vous devez être prudent et savoir ce que vous faites.
J'ai eu le même problème. J'ai remarqué que mon contexte de base de données (EF4) situé dans le projet dll n'était pas reconnu pour une raison quelconque. Je l'ai supprimé et créé un autre à la place. et cela l'a résolu pour moi.
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 tables pluralisées (*) (sur lesquels SQLMETAL ajoute, par défaut, une lettre "s" à la fin) font référence à des classes générées par SQLMETAL.
Depuis, j’ai récemment désactivé la pluralisation de noms, après avoir régéré certaines classes liées à la base de données, certaines d’entre elles ont perdu leur préfixe "s". Par conséquent, toutes les références aux classes de table affectées sont devenues invalides. Pour cette raison, j'ai plusieurs erreurs de compilation telles que:
'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 l'option Visual Studio> Menu Outils> Options> Outils de base de données> Concepteur O/R> La pluralisation de noms est activée, du code SQLMETALl Le générateur ajoutera une lettre "s" à la fin de certaines classes de la table générée, bien que la table n'ait pas de suffixe "s" sur la base de données cible. Pour plus d'informations, consultez http://msdn.Microsoft.com/en-us/library/bb386987(v=vs.110).aspx
Cet article a beaucoup de bons conseils. Je viens d'ajouter un de plus.
J'avais le même problème, mais aucune des réponses fournies ne le réglait auparavant. Apparemment, cela pourrait être un problème avec le fichier .csproj. Pour une raison quelconque, les références à des fichiers qui ne figuraient même nulle part dans mon code étaient toujours "manquantes".
Ouvrez votre fichier .csproj avec un éditeur de texte et recherchez les fichiers manquants, supprimez-les, enregistrez-les et soyez heureux.
J'ai aussi eu ce problème aujourd'hui. Mine a été causée par une dépendance cyclique . Le projet A a référencé le projet B et vice versa.
J'ai eu le même problème. Supprimer et ajouter manuellement les dll n'a pas aidé. ClassLibraries n'a pas compilé pour tous les projets et manquait dans le dossier ...\bin\Debug du projet [parce que j'ai nettoyé la solution par erreur]. Étant donné que la bibliothèque de classes n’a pas compilé, cela signifie qu’il peut y avoir des erreurs quelque part dans l’un de ces sous-projets .
Solution: Comme mes dll étaient là pour le dossier ...\bin\Release , j'ai essayé de reconstruire en mode Release et j'ai trouvé une erreur sur une ligne dans l'un des sous-projets. La résolution de l'erreur et la reconstruction de la solution ont permis d'éliminer l'erreur de génération.
dans mon cas, je travaillais sur une branche de master. J'ai donc vérifié la branche principale, lancé une construction, puis vérifié ma branche. Cela a résolu le problème. Si vous êtes déjà en master, je vous suggère de vérifier le commit précédent, puis de le construire.
Dans VS 2015, la suppression de "Analyseurs" sous "Références" a résolu le problème
ce qui m'est arrivé aujourd'hui, tel que décrit par Vidar.
J'ai une erreur de construction dans une bibliothèque d'assistance (référencée par d'autres projets) et au lieu de me signaler une erreur dans la bibliothèque d'assistance, le compilateur affiche une liste des erreurs de type MetaFile-not-found Après avoir corrigé l'erreur de construction dans Helper Library, les erreurs MetaFile ont disparu.
Y at-il un paramètre dans VS pour améliorer cela?
Cela semble se produire lorsque vous extrayez une solution avec plusieurs projets qui ont des références entre eux, et que vous ne l'aviez pas construite auparavant. Si vous avez des références directes aux dll, au lieu de référencer le projet, vous obtiendrez le message ..___. Vous devez toujours utiliser l'onglet Projets de la boîte de dialogue Ajouter une référence pour ajouter une référence à un projet dans la même solution. De cette manière, VS peut connaître le bon ordre dans lequel construire la solution.
J'avais un problème similaire. J'ai supprimé des classes et une interface, après quoi mes versions ont commencé à échouer.
- supprime toutes les générations afin qu'aucune génération de projet (gestionnaire de configuration)
- vérifier l'ordre de construction (faire une capture d'écran et la mettre dans Paint: D)
- activer un par un et faire chaque fois nettoyer et reconstruire et construire.
- Vous connaissez maintenant le projet qui a échoué. :-)
Dans ma situation, j’avais un dossier avec une interface à l’intérieur de ………. FooSolution.StupidProject.Interfaces Ce qui s’est passé, c’est que j’ai commenté l’interface IUnicorns (FooSolution.StupidProject.Interfaces.IUnicorns), de sorte qu’elle n’était plus utilisée . Aucun autre projet n’a été utilisé par IUnicorn. Tout était bien.
Cependant… D'autres projets utilisaient encore des instructions dans ce dossier:
using FooSolution.StupidProject.Interfaces
Solution:
Au lieu de commenter l'interface comme,
// interface publique IUnicorn {
J'ai aussi commenté l'espace de noms au-dessus de l'interface, comme ceci:
// namespace FooSolution.StupidProject.Interfaces
//{
// public interface IUnicorn {
- J'ai cherché dans mes autres projets et je me suis assuré qu'il n'y avait plus moyen d'utiliser cet espace de noms!
- Nettoyer et reconstruire et un bon café ;-)
Conclusion: Vérifiez vos utilisations dans d’autres projets.
Pour moi, Visual Studio avait créé un nom de projet.v11 de type "Options utilisateur de la solution Visual Studio". J'ai supprimé ce fichier et redémarré et tout allait bien.
Je suis d'accord avec la plupart des réponses affichées ici. Cependant, si toutes les solutions suggérées ne fonctionnent pas, considérez que vous avez probablement un autre type d'erreur dans votre liste d'erreurs, empêchant VS de créer le projet DLL nécessaire aux autres projets. Alors, peu importe l'ordre de construction ou la configuration, vous ne pourrez pas vous débarrasser de l'erreur "métadonnées" tant que les autres problèmes ne seront pas résolus.
Pour moi était de supprimer/supprimer tout le dossier .vs (qui est un invisible) puis:
- Build
- Rebuild
et fait.