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'essaye de modifier. J'ai remarqué plus tôt que lorsque j'ai tapé DbCommand, visual studio ne faisait aucune coloration syntaxique dessus, et j'utilise using System.Data.Common.

Même si rien n'a été mis en évidence, le projet semblait bien fonctionner dans mon navigateur. J'ai donc décidé d'exécuter le débogueur pour voir si les choses fonctionnaient vraiment comme elles le devraient.

Chaque fois que la classe qui n'a pas fait la mise en évidence est appelée, je reçois le "the source file is different from when the module was built"message.

J'ai nettoyé la solution et l'ai reconstruite plusieurs fois, supprimé les 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 toujours 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 la source peut-elle être différente du binaire alors que je viens de la respecter?
• Y a-t-il un moyen de donner du sens au studio visuel, ou est-ce que je manque juste quelque chose?

J'ai eu ce problème en exécutant une application console où la source différente était la source qui avait le point d'entrée (static void Main). La suppression des répertoires bin et obj et une reconstruction complète semblaient corriger cela, mais chaque fois que je modifiais le code, il devenait de nouveau obsolète.

La raison pour laquelle j'ai trouvé cela était:

1. J'avais coché "Ne construire que les projets de démarrage et les dépendances sur Exécuter" (Outils -> Options -> Projets et solutions -> Construire et exécuter)
2. Dans Configuration Manager, mon projet de démarrage n'avait pas coché "Build"

(Pour # 2 -> accessible via la barre d'outils sous la liste déroulante 'Debug / Release'.)

J'avais juste le même problème, mes projets étaient tous dans la même solution, donc ils utilisaient des références de projet à projet, donc comme l'un a changé, les autres auraient dû être mis à jour. Cependant ce n'était pas le cas, j'ai essayé de construire, reconstruire, fermer VS2010, extraire une nouvelle copie de notre contrôle de source. Rien de tout cela n'a fonctionné, j'ai finalement essayé de faire un clic droit sur le projet et de reconstruire chaque projet individuellement. Cela a mis à jour les fichiers .dlls et .pdb pour 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

1. Supprimez simplement le répertoire bin du projet dans lequel la DLL est générée.
2. Reconstruisez le projet.
3. Supprimez les références du projet qui font référence à la DLL.
4. Incluez à nouveau la référence.
5. Prendre plaisir.

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 faire référence au 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 Chemin d'accès physique dans l'Explorateur de fichiers et assurez-vous que vous utilisez ce dossier pour remplacer vos DLL.

Quelques éléments à vérifier:

Avez-vous vérifié les références de vos projets?

Avez-vous un serveur Web démarré par Visual Studio toujours 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):

_{(source: msdn.com )}

Faites un clic droit et fermez / sortez. Vous pouvez en avoir plusieurs. Pouvez-vous déboguer vos modifications maintenant?

Exécutez-vous la version de débogage mais n'avez-vous construit que la version finale (ou vice versa)?

La compilation a-t-elle réussi? Je sais que j'ai cliqué sur "il y a eu des erreurs, voulez-vous quand même continuer?" message plusieurs fois sans s'en rendre compte.

Avec les services Web, le problème peut être provoqué à l'aide de la commande Visual Studio «Afficher dans le navigateur». Cela place les fichiers DLL et PDB du service dans les dossiers bin et obj. Lors de l'accès au service Web à partir d'un client, Visual Studio utilise en quelque sorte la PDB dans le dossier bin (ou obj), mais il utilise la DLL dans le dossier de génération de sortie du projet. Il existe quelques solutions de contournement:

1. Essayez de supprimer les fichiers DLL et PDB dans les fichiers bin et obj du service Web.
2. Essayez de cliquer sur "Afficher dans le navigateur" dans Visual Studio.

Si vous avez déjà obtenu l'erreur d'incompatibilité du 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 -> Déboguer les fichiers source" sur le côté 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.

J'ai juste eu ce problème.

J'ai essayé tout ce qui précède, mais seul cela a fonctionné:

• supprimez le fichier .pdb de la solution.
• supprimer les fichiers .obj incriminés (pour le fichier signalé non synchronisé)

construire la solution.

Cela a résolu le problème pour toutes les versions à venir pour moi.

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 remettez l'option 'Solutions Configurations' sur «Debug»

Cela a fonctionné pour moi. L'étape 3 est facultative - cela fonctionnait bien lorsque je l'ai changé en "Release" mais je voulais le changer.

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 NOUVELLE solution. J'ai eu un chemin de l'éditeur de liens défini pour regarder dans le répertoire de sortie de la solution ANCIENNE.

Le basculement de mon projet pour rechercher dans le répertoire de sortie de la nouvelle solution a résolu ce problème pour moi.

J'ai eu ce problème et il s'avère que j'exécutais mon application console en tant qu'application Windows. Le basculement du type de sortie vers la console a résolu le problème.

J'ai eu le même problème. Pour résoudre ce problème, j'ai utilisé le "Release Mode" pour déboguer dans VS2013. Ce qui me suffit, car je travaille dans un addon node js \ c ++.

Déchargez le projet contenant le fichier à l'origine de l'erreur.

Rechargez le projet.

Fixé

Dans Visual Studio 2017, la suppression du dossier .vs masqué a résolu ce problème pour moi.

Mon problème était que j'avais deux projets dans ma solution. Le second était un projet de test utilisé pour appeler le premier. J'avais choisi le chemin d'accès aux références dans le dossier de version du dossier bin.

Ainsi, chaque fois que je modifiais le code du premier projet et que je le reconstruisais, cela mettait à jour les dll dans le dossier de débogage mais le projet appelant pointait vers le dossier de version, ce qui me donnait 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 version et l'avez définie sur la dll dans le dossier de débogage, le problème a disparu.

solution: - le problème est: - si vos certains projets dans une solution, se réfèrent à d'autres projets, alors parfois la dll de certains projets, ne se mettra pas à jour automatiquement, chaque fois que vous construisez la solution, certains projets auront des dll de construction précédentes, pas dernières dll

vous devez aller manuellement et copier la dll du dernier projet de construction dans le projet référencé

J'utilisais Visual Studio 2013 et j'avais un projet existant sous contrôle de code source.
J'avais téléchargé une nouvelle copie du contrôle de source vers un nouveau répertoire.
Après avoir apporté des modifications à 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 virtualDirectorynœud avec le répertoire vers la nouvelle copie et enregistrez-le.

Mon problème était que j'avais un webservice dans le projet et j'ai changé le chemin de construction.

La restauration du chemin de construction par défaut a résolu mon problème.

J'ai eu ce même problème et j'ai suivi la majorité des conseils dans les autres réponses affichées ici, rien ne semblait fonctionner pour moi.

J'ai finalement ouvert IIS et recyclé le pool d'applications pour mon application Web. J'ai la version 8.5.9600 d'IIS, 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 désormais atteints comme prévu. Je pense que faire cela avec la suppression des dossiers bin et obj a aidé ma situation.

Bonne chance!

Je sais que c'est une vieille question, mais j'ai juste eu 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 très bien. J'ai également supprimé l'ancien répertoire pour faire bonne mesure.

J'ai aussi vécu cela. 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.

Cette erreur se produit également si vous essayez d'apporter des modifications à un fichier source qui ne fait 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é la source car le .dll avait été construit sur la même machine et connaissait le chemin d'accès à la source. Évidemment, la modification d'un tel fichier ne fera rien à moins que vous ne reconstruisiez le projet référencé.

1. Supprimez tous les points d'arrêt.
2. Reconstruire.
3. Terminé

À Visual Studio 2015, en utilisant C ++, ce qui a résolu pour moi le the source file is different from when the module was builtproblème était

• redémarrez Visual Studio.

Déboguer-> démarrer sans débogage.

Cette option a fonctionné pour moi. J'espère que cela t'aides!

Vérifiez si l'emplacement que vous avez indiqué en utilisant mex () dans Matlab est correct (contient les fichiers lib et obj qui sont modifiés à la dernière date à laquelle vous avez compilé 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:

1. properties -> Config properties -> General -> Config type -> static library

2. properties -> Propriétés de configuration -> Général -> Extension cible = .lib (au lieu d'exe)

Assurez-vous que les répertoires de sortie et intermédiaires correspondent au répertoire Matlab dans

1. properties -> Config properties -> General -> Output directory
2. properties -> Propriétés de configuration -> Général -> Répertoire intermédiaire

Dans mon cas, la réponse de @ Eliott ne fonctionne pas. Pour résoudre ce problème, j'avais exclu / inclure du projet mon fichier défectueux, et également nettoyer et reconstruire 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.

Je reçois 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 qui ont à voir avec la façon dont le développeur d'origine a configuré ce projet.)

Lorsque je change le fichier et le reconstruit , cela le corrige la plupart du temps. Je sais que cela semble idiot, mais j'essayais juste de déboguer du code pour voir pourquoi cela faisait quelque chose de bizarre alors que je ne l'ai 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..