Le fichier de métadonnées '.dll' est introuvable.

Question

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

C'est ainsi que je référence mes contrôles d'utilisateur :

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

Cela se produit après chaque échec de la compilation. La seule façon d'obtenir la compilation de la solution est de commenter tous mes contrôles utilisateur et de recompiler le projet, puis de décommenter les contrôles utilisateur et tout va bien.

J'ai vérifié les ordres de construction 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 avait un bug avec la longueur. Est-ce un problème possible ?

C'est très ennuyeux et le fait de devoir commenter, construire et décommenter la construction devient extrêmement fatigant.

Answer 1

Pour moi, le problème était une erreur qui n'apparaissait pas dans le résultat de la compilation, à savoir que j'avais deux classes utilitaires qui étaient dans des espaces de noms différents au départ. J'ai modifié l'espace de noms de la seconde pour qu'il corresponde à celui de la première (sans savoir qu'il y avait une autre classe utilitaire dans la première), et c'est à ce moment-là que l'erreur a commencé à se produire.

J'imagine que l'erreur de sortie de compilation est apparue parce que le fichier DLL de la bibliothèque Logic Layer n'a pas pu être construit et que l'application principale ne l'a pas trouvé.

La solution consistait à replacer la deuxième classe utilitaire dans un espace de noms différent, et c'est à ce moment-là que les véritables erreurs de construction ont commencé à affluer. Après les avoir résolues, la construction s'est déroulée sans problème.

En résumé, si l'une des solutions précédentes ne fonctionne pas pour vous, il se peut que vous ayez supprimé des erreurs dans le code que Visual Studio ne montre pas. Essayez donc de retracer les étapes de votre codage et vérifiez les irrégularités éventuelles.

PS : C'était dans Visual Studio 2015 Community Edition.

Answer 2

L'IDE Visual Studio n'effectue aucune construction en coulisse, c'est l'application Msbuild qui le fait. L'IDE VS se contente essentiellement de construire le fichier de projet qui est utilisé par Msbuild et il arrive souvent qu'il fasse des erreurs si vous laissez l'IDE se débrouiller tout seul. Si vous obtenez le message Metadata file '.dll' could not be found il est probablement dû au fait que les assemblages corrects/attendus ne sont pas trouvés. Il se peut donc que Visual Studio crée un fichier de projet pour une application avec un framework 4.5 et s'attende à des assemblages 4.5, alors que vous faites référence à des assemblages 4.0. Vérifiez donc les incompatibilités dans les paramètres de Visual Studio ou allez dans le fichier de projet vous-même, et corrigez manuellement le problème en spécifiant le chemin correct. <Reference Include="C:\\correct path to assembly\\yourAssembly.dll" /> .

Answer 3

Dans mon cas, à l'intérieur de mon Web.config en changeant ce

<?xml version="1.0" encoding="utf-8"?>

à ce

<?xml version="1.0"?>

a réglé mon problème

Answer 4

Lorsque je faisais une construction, 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 de ce type s'affiche pendant quelques secondes, puis elle disparaît et revient 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 à dépanner la première erreur, mais le véritable problème s'est avéré être dû à la deuxième 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.

Dans mon interface, j'avais ceci :

    Task<IList<Defect>> LoadDefects(Asset asset);

Mais dans ma mise en œuvre réelle, 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 que j'ai mis à jour l'interface comme ceci :

    Task<IList<Defect>> LoadDefects(Inspection inspection);

Il semble donc que la mise en cache dans VS ait entraîné l'affichage de l'erreur CS0006 alors que le problème réel était l'erreur CS1503.

Answer 5

Dans mon cas, cela m'est arrivé lorsque je faisais référence à des paquets NuGet localement et que j'ai déplacé leur répertoire ailleurs, j'ai changé le chemin d'accès dans le fichier NuGet.Config mais j'ai malheureusement découvert que je devais modifier le .csproject manuellement pour mettre à jour le chemin de référence, mais le message d'erreur CS0006 était très loin de décrire ce problème. En général, cela se produit également lorsqu'il y a une référence à une DLL qui ne peut être trouvée, pour pouvoir identifier le problème, recherchez vos références dans le projet avec le problème, vous trouverez certaines références avec une icône d'avertissement associée à eux, essayez de corriger ceux-ci et il devrait fonctionner comme prévu.