le fichier source est différent de celui de la construction du module
Ça me rend fou.
J'ai un projet assez volumineux que j'essaie de modifier. J'ai remarqué précédemment que lorsque j'ai tapé DbCommand, Visual Studio n'a pas mis en évidence de syntaxe, et j'utilise System.Data.Common.
Même si rien n’était mis en évidence, le projet semblait fonctionner correctement dans mon navigateur. J'ai donc décidé de lancer le débogueur pour voir si tout fonctionnait correctement.
Chaque fois que la classe qui n'a pas fait la surbrillance s'appelle, je reçois le message "the source file is different from when the module was built".
J'ai nettoyé la solution et l'ai reconstruite plusieurs fois, j'ai supprimé des fichiers tmp, suivi toutes les instructions ici Obtenir "Le fichier source est différent de celui de la construction du module." , a redémarré le serveur Web et il me dit tout de même que les fichiers source sont différents alors qu'ils ne le sont clairement pas.
Je ne peux tester aucun des codes que j'ai écrits aujourd'hui à cause de cela.
- Comment le source peut-il être différent du binaire quand je viens de m'y conformerit?
- Existe-t-il un moyen de donner un sens au studio visuel ou suis-je Je manque juste quelque chose?
J'ai eu ce problème en exécutant une application de console où la source qui était différente était la source qui avait le point d'entrée (static void Main). Supprimer les répertoires bin et obj et procéder à une reconstruction complète semblaient corriger cela, mais chaque fois que je modifiais le code, le code était périmé.
La raison pour laquelle j'ai trouvé ceci était:
- J'avais coché "Construire uniquement les projets de démarrage et les dépendances sur Exécuter" (Outils -> Options -> Projets et solutions -> Construire et exécuter)
- Dans Configuration Manager, la case "Construire" n'était pas cochée dans mon projet de démarrage.
(Pour # 2 -> accessible via la barre d’outils dans la liste déroulante 'Debug/Release'.)
J'avais juste le même problème, mes projets étaient tous dans la même solution, ils utilisaient donc les références de projet à projet, de sorte qu'un changement a été apporté, les autres auraient dû être mis à jour. Cependant, ce n’était pas le cas, j’ai essayé de construire, de reconstruire, de fermer VS2010, d’en extraire une nouvelle copie de notre contrôle de source. Tout cela n'a pas fonctionné. Ce que j'ai finalement essayé d'essayer, c'est de cliquer avec le bouton droit de la souris sur le projet et de reconstruire chaque projet individuellement. Cela a mis à jour les fichiers .dll et .pdb afin que je puisse déboguer.
Le problème ici est que votre dll et/ou vos fichiers pdb ne sont pas synchronisés.
Suivez ces étapes
- Supprimez simplement le répertoire bin du projet où la DLL est générée.
- Reconstruisez le projet.
- Supprimer la référence du projet qui fait référence à la DLL.
- Inclure à nouveau la référence.
- Prendre plaisir.
Quelques points à vérifier:
Avez-vous vérifié les références de vos projets?
Avez-vous un serveur Web démarré par Visual Studio en cours d'exécution? Vérifiez la barre d'état système et recherchez une page avec une icône de rouage (vous pouvez en avoir plusieurs):
Faites un clic droit et fermez/quittez-le. Vous pouvez en avoir plus d'un. Pouvez-vous déboguer vos modifications maintenant?
Exécutez-vous la version de débogage mais n’avez-vous construit que la version (ou vice-versa)?
La compilation a-t-elle réellement réussi? Je sais que j'ai cliqué sur "il y avait des erreurs, voulez-vous continuer quand même?" message plusieurs fois sans s'en rendre compte.
En plus de ces réponses, j'ai eu le même problème lors du remplacement de nouvelles DLL par d'anciennes en raison du mauvais chemin. Si vous obtenez toujours cette erreur, vous ne pouvez pas indiquer le mauvais chemin pour les DLL. Accédez au gestionnaire IIS et cliquez sur le site Web qui utilise vos DLL. Dans la fenêtre de droite, cliquez sur Paramètres avancés et accédez au chemin du dossier du chemin d'accès physique dans l'Explorateur de fichiers. Assurez-vous que vous utilisez ce dossier pour remplacer vos DLL.
Avec les services Web, le problème peut être provoqué à l'aide de la commande "Afficher dans le navigateur" de Visual Studio. Cela place les fichiers DLL et PDB du service dans les dossiers bin et obj. Lorsque vous entrez dans le service Web à partir d'un client, Visual Studio utilise le PDB dans le dossier bin (ou obj), mais utilise le DLL dans le dossier de génération de sortie du projet. Il y a quelques solutions de contournement:
- Essayez de supprimer les fichiers DLL et PDB dans les fichiers bin et obj du service Web.
- Essayez de cliquer sur "Afficher dans le navigateur" dans Visual Studio.
Si vous avez déjà rencontré l'erreur d'incompatibilité de fichier source, Visual Studio a peut-être ajouté le nom de fichier à une liste noire. Vérifiez les propriétés de votre solution. Choisissez "Propriétés communes -> Fichiers sources de débogage" dans la partie gauche de la boîte de dialogue. Si les fichiers source de votre service Web apparaissent dans le champ "Ne cherchez pas ces fichiers source", supprimez-les.
Je viens d'avoir ce problème.
J'ai essayé tout ce qui précède, mais seulement cela a fonctionné:
- supprimez le fichier .pdb de la solution.
- supprimer les fichiers .obj incriminés (pour le fichier signalé comme non synchronisé)
construire la solution.
Cela corrigeait le problème pour toutes les constructions qui allaient de l'avant.
Ma solution:
J'avais inclus un projet existant d'une solution différente dans un nouveau fichier de solution.
Je n'ai pas remarqué que, lorsque le projet existant a été reconstruit, il mettait la sortie finale dans le répertoire de sortie de la solution NEW. Un chemin de l'éditeur de liens a été défini pour examiner le répertoire de sortie de l'ancienne solution.
Le basculement de mon projet vers le répertoire de sortie de la nouvelle solution a résolu ce problème.
Voici comment j'ai résolu le problème dans Visual Studio 2010:
1) Changez l'option "Solutions Configurations" de "Debug" à "Release"
2) Démarrer le débogage
3) Arrêtez le débogage et rétablissez l'option "Solutions Configurations" sur "Debug"
Cela a fonctionné pour moi. L'étape 3 est facultative - elle fonctionnait bien lorsque je l'ai changée en "Libérer" mais je voulais la remettre en place.
Mon problème était que j'avais deux projets dans ma solution. Le second était un projet test appelé le premier. J'avais choisi le chemin d'accès aux références dans le dossier de publication du dossier bin.
Ainsi, chaque fois que je modifiais le code du premier projet et le reconstruisais, il mettait à jour les dll dans le dossier de débogage, mais le projet appelant pointait vers le dossier de publication, me donnant ainsi l’erreur, "le fichier source est différent de celui du module a été construit."
Une fois que j'ai supprimé la référence à la dll du projet principal dans le dossier de publication et que je l'ai configurée sur la dll du dossier de débogage, le problème a disparu.
J'ai eu ce problème et il s'est avéré que j'exécutais mon application console en tant qu'application Windows. La commutation du type de sortie sur la console a résolu le problème.
Dans Visual Studio 2017, la suppression du dossier .vs masqué du problème résolu pour moi.
J'ai eu le même problème. Pour résoudre ce problème, j’ai utilisé le "mode de libération" pour déboguer dans VS2013. Ce qui me suffit, car je travaille dans un addon de noeud js\c ++.
Déchargez le projet contenant le fichier à l'origine de l'erreur.
Rechargez le projet.
Fixé
J'utilisais Visual Studio 2013 et j'avais un projet existant sous contrôle de source.
J'avais téléchargé une nouvelle copie du contrôle de source dans un nouveau répertoire.
Après avoir modifié la nouvelle copie, lors de la construction, j'ai reçu l'erreur en question.
Ma solution:
1) Ouvrez Documents\IISExpress\config\applicationhost.config
2) Mettez à jour le noeud virtualDirectory avec le répertoire sur la nouvelle copie et sauvegardez-le.
Cette erreur se produit également si vous essayez de modifier un fichier source ne faisant pas partie du projet.
Je déboguais une méthode à partir d'un .dll d'un autre de mes projets, où Visual Studio avait assez utilement chargé le code source, car le fichier .dll avait été créé sur le même ordinateur et connaissait le chemin d'accès au code source. Évidemment, modifier un tel fichier ne va rien faire à moins de reconstruire le projet référencé.
Dans Visual Studio 2015, en utilisant C++, ce qui a résolu pour moi le problème the source file is different from when the module was built
- redémarrez Visual Studio.
Mon problème était que j'avais un service web dans le projet et que je changeais le chemin de compilation.
La restauration du chemin de construction par défaut a résolu mon problème.
J'ai aussi vécu ça. Je viens d'ouvrir le dossier obj sur le projet, puis ouvrez le dossier de débogage, supprimez le fichier .pdb et c'est tout.
Dans mon cas, la réponse de @ Eliott ne fonctionne pas. Pour résoudre ce problème, j’avais Exclude/Include From Project comme fichier défectueux, ainsi que Clean et Rebuild la solution.
Après ces actions, mon fichier avec mes dernières modifications et le débogueur sont restaurés.
J'espère que cette aide.
- Supprimer tous les points d'arrêt.
- Reconstruire.
- Terminé
solution:- le problème est le suivant: - si vous avez des projets dans une solution, référez-vous à d'autres projets, alors parfois, la dll de certains projets ne sera pas mise à jour automatiquement, chaque fois que vous construirez la solution,. avoir des dll de construction précédentes, pas les dernières dll
vous devez aller manuellement et copier la DLL du dernier projet de construction dans le projet référencé
Je rencontre ce problème lors du débogage, parfois avec Visual Studio, mais lorsque l'application est servie par IIS . (Nous devons développer sous cette forme pour des raisons compliquées liées à la façon dont le développeur d'origine a configuré ce projet.)
Quand je change le fichier et reconstruit , cela le corrige souvent. Je sais que cela semble idiot, mais j’essayais juste de déboguer du code pour voir pourquoi il faisait quelque chose de bizarre alors que je ne l’avais pas changé depuis un moment, et j’ai essayé une douzaine de choses à partir de cette page, mais cela a été corrigé simplement en changeant le fichier..
Vérifiez si l'emplacement que vous avez indiqué à l'aide de mex () dans Matlab est correct (contient les fichiers lib et obj modifiés à la date de la dernière compilation de la bibliothèque dans Visual studio).
Si ce n'est pas le cas:
Assurez-vous que vous compilez Visual Studio dans un mode qui enregistre les fichiers .lib:
properties -> Propriétés de configuration -> Général -> Type de configuration -> Bibliothèque statique
propriétés -> Propriétés de configuration -> Général -> Extension de la cible = .lib (au lieu de exe)
Assurez-vous que les répertoires de sortie et intermédiaires correspondent au répertoire Matlab dans
- properties -> Propriétés de configuration -> Général -> Répertoire de sortie
- properties -> Config properties -> General -> Répertoire intermédiaire
J'ai eu ce même problème et j'ai suivi la majorité des conseils dans les autres réponses postées ici, rien ne semblait fonctionner pour moi.
J'ai finalement ouvert IIS et recyclé le pool d'applications de mon application Web. J'ai IIS version 8.5.9600, j'ai cliqué avec le bouton droit sur mon application Web, puis: Déployer> Recycler> Recycler le pool d'applications> OK.
Cela semble avoir résolu le problème, les points d'arrêt étant maintenant atteints comme prévu. Je pense que cela, ainsi que la suppression des dossiers bin et obj, ont aidé ma situation.
Bonne chance!
Déboguer-> démarrer sans déboguer.
Cette option a fonctionné pour moi. J'espère que cela t'aides!
Je sais que c’est une vieille question, mais je n’avais que le même problème et je voulais poster ici au cas où cela aiderait quelqu'un d’autre. J'ai eu un nouvel ordinateur et le service informatique a fusionné mon ancien ordinateur avec le nouveau. Lorsque j'ai configuré TFS, j'ai mappé un chemin local différent de celui que j'utilisais précédemment sur un lecteur interne supplémentaire. L'ancien chemin existait toujours à partir des données fusionnées sur mon disque dur afin que je puisse toujours créer et exécuter. Mes chemins IIS pointaient également vers l'ancien répertoire. Une fois que j'ai mis à jour IIS sur le chemin correct, j'ai pu déboguer parfaitement. J'ai également supprimé l'ancien répertoire pour faire bonne mesure.