Le fichier de métadonnées «.dll» est introuvable


723

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.


5
J'ai eu un problème similaire (obtenir la même erreur que celle indiquée dans le titre) et je l'ai géré en nettoyant et en reconstruisant le projet. Pour référencer correctement d'autres projets, je n'en ai aucune idée ..
phoad

Cette question a-t-elle une réponse qui serait considérée comme acceptée? Je trouve que celui de @Matt_Bro est assez bon.
demongolem

4
J'ai marqué la réponse de Matt car elle semble avoir fonctionné pour la plupart des gens, mais cela n'a pas résolu mon problème d'origine. Je pense toujours que cela est lié à la limite de chemin d'accès maximale de Windows. Voir ma réponse ci-dessous.
Oliver

1
le doublon possible du fichier
Des Horsley

J'ai essayé toutes les réponses ci-dessus et malheureusement rien n'a fonctionné dans mon cas. J'ai rencontré 2 erreurs 1. Fichier .dll manquant 2. Méthode déjà définie à un autre endroit avec les mêmes paramètres J'ai d'abord effacé la deuxième erreur en supprimant la fonction qui a été dupliquée à un autre endroit. Ma première erreur - c'est-à-dire le fichier .dll manquant a été résolue d'elle-même. Je veux dire si vous avez plus d'une seule erreur avec une erreur de fichier manquant .dll! Veuillez d'abord essayer de résoudre les autres erreurs. Peut-être que l'erreur .dll se résout d'elle-même!
Un utilisateur du

Réponses:


908

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:

Instructions Gif


177
Et, dans mon cas, même si la case était cochée, la décocher et la cocher à nouveau corrigeait le problème.
ngm

13
Cela a résolu mon problème - je devais le faire pour les modes Release et Debug sur les propriétés de la solution. Merci!
theJerm

133
La décoche / vérification simple n'a pas résolu le problème, j'ai donc dû faire les étapes suivantes: - solution propre - décochez toutes les cases de construction - redémarrez VS - cochez toutes les cases de construction
frankie

27
L'autre chose à faire est de vérifier chacune des dépendances du projet, pour une raison quelconque, cela ne se faisait pas automatiquement. Propriétés de la solution -> Propriétés communes -> Dépendances du projet.
Anicho

9
décochez -> cocher a fonctionné brièvement pour moi puis le problème est revenu. J'ai ensuite redémarré Visual Studio et le problème a disparu.
DeveloperDan

224

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 .


24
Cela a résolu le problème pour moi. Il convient également de mentionner que les .suofichiers sont masqués. Vous devrez donc configurer votre explorateur pour afficher les fichiers cachés.
George Howarth

6
Je travaille avec le projet Xamarin et le fichier .suo se trouve dans le dossier .vs /. J'ai essayé de le supprimer et cela n'a pas résolu mon problème

VS2013 - J'ai dû déplacer mon espace de travail TFS vers un autre emplacement. Après avoir terminé cela, j'ai commencé à obtenir cette erreur. La suppression du fichier sou a fonctionné pour moi.
Vin

40
Cela a également fonctionné pour moi. Mais dans Visual Studio 2015, le .suofichier est à la fois masqué et se trouve dans un .vsrépertoire masqué à côté de .sln. par exemple: si le fichier de solution est à la c:\foo\mysolution.slnrecherchec:\foo\mysolution\.vs\mysolution\v14\.suo
Wyck

6
Pour VS2017, pour plus de simplicité, je viens de supprimer le .vsdossier caché à la place, ce qui a également supprimé le .suofichier. J'ai rouvert la solution, corrigé une autre erreur non liée et le problème a été résolu.
user3613932

183

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.


9
J'ai pu résoudre le problème en faisant correspondre le cadre du projet à la version supérieure indiquée dans le message d'avertissement en cliquant avec le bouton droit sur le projet> Propriétés> Application> Cadre cible.
StronglyTyped

1
Même chose pour moi, en utilisant vs2015.
bruno.bologna

oui. c'est exactement ce qui m'est arrivé aussi. VS 2015
KevinDeus

Merci! Cela a résolu mon problème. VS 2015 après la mise à niveau du projet vers .Net Framework 4.7.1.
DHoover

Wow, cela m'a arrangé. Le nouveau projet visait une version .net différente. Je ne peux pas croire qu'il n'y ait pas de contrôle pour cela même dans vs2017.
Douglas Gaskell

104

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 .


4
Mon problème était les dépendances d'ordre de construction / projet. Supprimer et ajouter des références à partir d'autres projets corrigera cela (je pense) mais vous pouvez aussi le faire vous-même.
Nacht - Reinstate Monica

4
J'ai fait face à ce problème en déclassant le .NET v4.5projet vers .NET v.4.
guneysus

1
La suppression de "%" du chemin de la DLL référencée m'a aidé
Boogier

1
La solution de la section 2 a fonctionné pour moi! J'ai eu une autre erreur et quand j'ai corrigé que les autres disparaissaient comme par magie.
Martin Johansson

1
J'ai eu le même problème que Boogier. Avait un% 20 dans mon nom de dossier au lieu d'un espace et la DLL recherchait un espace. J'ai passé tellement de temps à essayer toutes les autres corrections, alors que la vraie était la plus simple.
Lenny K

38

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.


2
Cela se produit également entre 4,5,2 Vs. 4.6
AzzamAziz

2
En effet, j'en avais un de 4.6.1 et le reste était de 4.5.2, merci!
Mason

7
Oui, chaque fois qu'une version du framework est différente, cela se produit. Grande erreur Microsoft!
Eric Schneider

Ouaip! J'essayais d'utiliser un .Net 4.7.1 .dll lorsque mon projet était .Net 4.6.1. L'avertissement a été masqué par d'autres éléments, mais aucune erreur à ce sujet. Mon erreur était un hareng rouge
Esaith

29

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


Vous avez ce problème après avoir annulé les modifications de git dans les fichiers de projet. Redémarré VS2015 et résolu le problème
Ludovic C

Cela devrait être marqué comme réponse acceptée. Cochez / décochez les cases prend plus de temps.
Alex

1
J'ai toujours ce problème avec VS2019 et cela l'a résolu pour moi, merci
pcdev

20

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 .



14

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.


14
Bien que ce correctif fonctionne, il ne résout pas réellement le problème et pourrait entraîner des problèmes sous-jacents. Tout d'abord, si vous travaillez avec du code dans un référentiel, il est mauvais de demander à un nouveau développeur de sauter à travers des cerceaux pour obtenir le code au point où il va se construire. Deuxièmement, pour voir les changements dans le projet référencé, vous devez le reconstruire manuellement à chaque fois. Veuillez consulter ma réponse pour une solution plus robuste au problème.
Matt_Bro

Dans mon cas, il ne construit même pas le projet individuellement, cela me donne la même erreur. Disons que mon nom de projet est "proj1", quand je le construis (manuellement comme vous l'avez dit) ça me donne Metadata file ...proj1.dll could not be found!
A-Sharabiani

14

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.


1
Pourriez-vous élaborer davantage votre réponse en ajoutant un peu plus de description sur la solution que vous proposez?
abarisone

Mon clone git a ajouté% à mon chemin de dossier, ce qui a résolu le problème.
Erik Bergstedt

@abarisone J'ai supprimé la chaîne "% 2c" du chemin, puis cela a fonctionné
masphei

1
C'était aussi mon problème, quand j'ai cloné le projet, il a été nommé en utilisant "% 20" au lieu d'un simple espace. Merci @abarisone, votre approche a résolu mon problème.
MA Cordeiro

Lorsque j'ai cloné mon projet à partir de TFS, il a également ajouté un% 20 pour une raison quelconque. La suppression a également résolu le problème pour moi.
Selthien

13

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.


Eh bien, j'étais sur le point de répondre de la même manière, dans mon cas, j'ai ajouté un nouveau projet ciblant .Net 4.5.x et cela a commencé à se produire lorsque, à partir de ce projet, j'ai ajouté une référence à un projet qui utilisait .Net 4.6.
Juan

12

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.

Merci beaucoup, cela a également fonctionné pour moi après avoir fait une autre construction échouée.
Iamsodarncool

Merci, ça l'a fait pour moi.
iaacp

10

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.


10

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).


1
Je ne sais pas pourquoi maintenant mais je menais mes projets depuis un an comme ça. mon sous-projet était 4.6.1 et le projet principal était 4.5.2. cela a fonctionné sans aucun problème. tout à coup, je reçois cette erreur mais je ne veux pas rétrograder le sous-projet car il a une fonctionnalité qui existe en 4.6.1 je ne crois pas que ce soit le problème. Microsoft explique qu'il devrait encore fonctionner
batmaci

TLDR: vérifiez les avertissements de compilation. C'est ce qui m'est arrivé mais avec une torsion. les projets étaient à 4.5.2. Ajout de nouveaux projets à 4.6. Packages de nuget installés sur les projets 4.6. 4,6 projets rétrogradés à 4,5,2. Les pépites attendaient 4.6. Résolution des déclassements de pépites.
w00ngy

9

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é.


8

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.

Faites un clic droit sur le "dossier" de référence dans l'explorateur de solutions, "supprimez les références non utilisées". J'ai fait ça sur tous mes projets dans cette solution, ça a fait l'affaire
Mathieu VIALES

8

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.


1
Ugh, ça. Tant de choses que Microsoft nécessite un redémarrage pour fonctionner à nouveau.
Yatrix

8

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.


J'ai également rencontré ce problème. Il n'y avait aucune erreur dans la liste d'erreurs, mais les résultats de génération ayant échoué dans DevOps ont montré l'erreur
amartin

7

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.


S'agit-il d'un commentaire, d'une réponse ou d'une nouvelle question? Notez également que OP est de 2009
OGM

8
Il s'agit d'une solution supplémentaire au même problème. Je sais que le PO est vieux, mais d'après les deux derniers articles, les gens trouvent encore d'autres causes. J'essaie juste de sauver le prochain gars de la frustration car aucune des autres solutions n'a fonctionné pour moi non plus.
Eric

4
Je ne critique la réponse de personne, je propose simplement une solution alternative au même symptôme.
Eric

7

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, l'erreur a été masquée jusqu'à ce que j'ouvre Visual Studio 2015 en mode Administrateur. Ce n'est qu'alors qu'il a montré l'erreur de compilation. Après avoir corrigé cela, je pouvais continuer.
SL Barth - Reinstate Monica

6

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.


6

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.


tu es un génie!!
Itamar

Je n'ai pas vu votre commentaire avant de le comprendre. Mais c'était mon problème.
L Johnson


6

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 ...


Je pense que tout le monde devrait chercher cette réponse. Regardez dans la fenêtre de sortie de la construction et voyez s'il y a des erreurs ou des avertissements, puis corrigez-les. Problème résolu. Merci Heinz Kessler pour votre réponse.
Captain America

5

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 #? .


5

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.


1
Cette!!! Bien que la réponse ci-dessus soit bonne, c'est quelque chose que j'ai complètement ignoré. Merci bon monsieur.
Rhys Johns

@RhysJohns happy coding :)))
Code_Worm

4

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 eu quelque chose de similaire récemment - à l'improviste, des centaines d'erreurs cs0006 dans le journal des erreurs, mais rien d'autre (et je l'ai parcouru avec un peigne très fin). Finalement (!) J'ai pensé à regarder la fenêtre de sortie, et il y avait une erreur de compilation signalée, et bien sûr dans le code, l'erreur avait un gribouillis rouge en dessous. Je ne sais pas pourquoi l'erreur n'a pas été signalée dans la fenêtre Erreurs. VS2017 Enterprise.
superbe

4

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.


4

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?


Je ne sais pas comment je n'ai rien changé et je n'ai pas d'événements ou de configurations de construction personnalisés
Oliver

4

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.


4

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.


Qu'est-ce qu'un "faux assemblage"? Peux-tu élaborer? (Répondez en développant votre réponse.)
Peter Mortensen
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.