il file sorgente è diverso da quando è stato creato il modulo

Questo mi sta facendo impazzire.

Ho un progetto piuttosto grande che sto cercando di modificare. Ho notato in precedenza che quando ho digitato DbCommand, Visual Studio non ha evidenziato alcuna evidenziazione della sintassi e sto usando using System.Data.Common.

Anche se non è stato evidenziato nulla, il progetto sembrava funzionare correttamente nel mio browser. Quindi ho deciso di eseguire il debugger per vedere se le cose funzionavano davvero come dovrebbero.

Ogni volta che viene chiamata la classe che non ha evidenziato l'evidenziazione, ricevo il "the source file is different from when the module was built"messaggio.

Ho ripulito la soluzione e ricostruita più volte, cancellato i file tmp, seguito tutte le indicazioni qui Come ottenere "Il file sorgente è diverso da quando è stato creato il modulo." , riavviato il server web e ancora mi dice che i file di origine sono diversi quando chiaramente non lo sono.

Non posso testare nessuno dei codici che ho scritto oggi per questo motivo.

• Come può la sorgente essere diversa dal binario quando l'ho appena rispettata?
• C'è un modo per dare un po 'di buon senso allo studio visivo, o mi manca qualcosa?

Ho riscontrato questo problema eseguendo un'app per console in cui la fonte diversa era la fonte che aveva il punto di ingresso (static void Main). L'eliminazione delle directory bin e obj e l'esecuzione di una ricostruzione completa sembrava correggere questo problema, ma ogni volta che ho apportato una modifica al codice, sarebbe diventato di nuovo obsoleto.

Il motivo che ho trovato per questo è stato:

1. Avevo selezionato "Crea solo progetti di avvio e dipendenze su Esegui" (Strumenti -> Opzioni -> Progetti e soluzioni -> Compila ed esegui)
2. In Configuration Manager, il mio progetto di avvio non aveva selezionato "Build"

(Per # 2 -> accessibile tramite la barra degli strumenti sotto l'elenco a discesa "Debug / Rilascio".)

Avevo lo stesso problema, i miei progetti erano tutti nella stessa soluzione, quindi utilizzavano riferimenti da progetto a progetto, quindi se uno è cambiato, gli altri avrebbero dovuto essere aggiornati. Tuttavia non è stato il caso, ho provato a compilare, ricostruire, chiudere VS2010, estrarre una nuova copia dal nostro controllo del codice sorgente. Niente di tutto questo ha funzionato, quello che ho finalmente provato è stato fare clic con il tasto destro sul progetto e ricostruire ogni progetto individualmente. Questo ha aggiornato i file .dll e .pdb in modo da poter eseguire il debug.

Il problema qui è che i tuoi file dll e / o pdb non sono sincronizzati.

Segui questi passi

1. Basta eliminare la directory bin dal progetto in cui viene generata la DLL.
2. Ricostruisci il progetto.
3. Rimuovere i riferimenti dal progetto che fanno riferimento alla DLL.
4. Includere di nuovo il riferimento.
5. Godere.

Oltre a queste risposte ho avuto lo stesso problema durante la sostituzione delle nuove DLL con quelle vecchie a causa del percorso sbagliato. Se continui a ricevere questo errore, potresti non fare riferimento al percorso sbagliato per le DLL. Vai al gestore IIS e fai clic sul sito Web che utilizza le tue DLL. Nella finestra di destra fai clic su Impostazioni avanzate e vai al percorso della cartella Percorso fisico su Esplora file e assicurati di utilizzare questa cartella per sostituire le DLL.

Alcune cose da controllare:

Hai ricontrollato i riferimenti del tuo progetto?

Hai un server Web avviato da Visual Studio ancora in esecuzione? Controlla la barra delle applicazioni e cerca una pagina con un'icona a forma di ingranaggio (potresti averne più di una):

_{(fonte: msdn.com )}

Fare clic con il tasto destro e chiuderlo / uscire. Potresti averne più di uno. Puoi eseguire il debug delle modifiche ora?

Stai eseguendo la versione di debug ma hai creato solo la versione di rilascio (o viceversa)?

La compilazione è riuscita effettivamente? So di aver selezionato "ci sono stati errori, vuoi continuare comunque?" messaggio un paio di volte senza rendersene conto.

Con i servizi Web, il problema può essere causato dall'utilizzo del comando "Visualizza nel browser" di Visual Studio. In questo modo i file DLL e PDB del servizio nelle cartelle bin e obj. Quando si accede al servizio Web da un client, in qualche modo Visual Studio utilizza il PDB nella cartella bin (o obj), ma utilizza la DLL nella cartella di compilazione dell'output del progetto. Ci sono un paio di soluzioni alternative:

1. Prova a eliminare i file DLL e PDB nel bin del servizio Web e nei file obj.
2. Prova a fare clic su "Visualizza nel browser" in Visual Studio.

Se in precedenza hai ricevuto l'errore di mancata corrispondenza del file di origine, Visual Studio potrebbe aver aggiunto il nome del file a una lista nera. Controlla le proprietà della tua soluzione. Scegli "Proprietà comuni -> Debug file sorgente" sul lato sinistro della finestra di dialogo. Se i file di origine del servizio Web vengono visualizzati nel campo "Non cercare questi file di origine", eliminarli.

Ho appena avuto questo problema.

Ho provato tutto quanto sopra, ma solo questo ha funzionato:

• eliminare il file .pdb per la soluzione.
• eliminare i file .obj offensivi (per il file segnalato non sincronizzato)

costruire la soluzione.

Questo ha risolto il problema per tutte le build che andavano avanti per me.

Ecco come ho risolto il problema in Visual Studio 2010:

1) Modifica l'opzione "Configurazioni soluzioni" da "Debug" a "Rilascio"

2) Avvia il debug

3) Interrompi il debug e riporta l'opzione "Configurazioni soluzioni" su "Debug"

Questo ha funzionato per me. Il passaggio 3 è facoltativo: funzionava bene quando l'ho cambiato in "Release" ma volevo cambiarlo di nuovo.

La mia soluzione:

Avevo incluso un progetto esistente da una soluzione diversa in un nuovo file di soluzione.

Non ho notato che quando il progetto esistente è stato ricostruito, stava inserendo l'output finale nella directory di output della NUOVA soluzione. Avevo un percorso del linker definito per esaminare la directory di output della VECCHIA soluzione.

Cambiare il mio progetto per cercare nella directory di output della nuova soluzione ha risolto questo problema per me.

Ho avuto questo problema e si è scoperto che stavo eseguendo la mia applicazione console come un'applicazione Windows. Il ripristino del tipo di output su console ha risolto il problema.

Ho avuto lo stesso problema. Per risolverlo ho usato la "modalità di rilascio" per eseguire il debug in VS2013. Il che è sufficiente per me, perché sto lavorando in un addon js \ c ++ del nodo.

Scarica il progetto che contiene il file che causa l'errore.

Ricarica il progetto.

Fisso

In Visual Studio 2017 l'eliminazione della cartella .vs nascosta nel risolto questo problema per me.

Il mio problema era che avevo due progetti nella mia soluzione. Il secondo era un progetto di prova utilizzato per chiamare il primo. Avevo scelto il percorso dei riferimenti dalla cartella di rilascio della cartella bin.

Quindi ogni volta che apportavo una modifica al codice del primo progetto e lo ricostruivo, aggiornava le dll nella cartella di debug ma il progetto chiamante puntava alla cartella di rilascio, dandomi l'errore ", il file sorgente è diverso da quando il modulo fu costruito."

Dopo aver eliminato il riferimento alla dll del progetto principale nella cartella di rilascio e averlo impostato sulla dll nella cartella di debug, il problema è scomparso.

soluzione: - il problema è: - se alcuni progetti in una soluzione fanno riferimento ad altri progetti, a volte la dll di alcuni progetti non si aggiornerà automaticamente, ogni volta che si crea la soluzione, alcuni progetti avranno DLL di build precedenti, non gli ultimi dll

devi andare manualmente e copiare la dll dell'ultimo progetto di build nel progetto di riferimento

Stavo usando Visual Studio 2013 e avevo un progetto esistente sotto il controllo del codice sorgente.
Avevo scaricato una nuova copia dal controllo del codice sorgente in una nuova directory.
Dopo aver apportato modifiche alla nuova copia, durante la creazione ho ricevuto l'errore in questione.

La mia soluzione:
1) Apri Documents\IISExpress\config\applicationhost.config
2) Aggiorna il virtualDirectorynodo con la directory alla nuova copia e salva.

Il mio problema era che avevo un webservice nel progetto e ho cambiato il percorso di compilazione.

Il ripristino del percorso di compilazione predefinito ha risolto il mio problema.

Ho avuto lo stesso problema e ho seguito la maggior parte delle indicazioni nelle altre risposte pubblicate qui, niente sembrava funzionare per me.

Alla fine ho aperto IIS e ho riciclato il pool di applicazioni per la mia applicazione web. Ho la versione 8.5.9600 di IIS, ho fatto clic con il pulsante destro del mouse sulla mia applicazione Web, quindi: Distribuisci> Ricicla> Ricicla pool di applicazioni> OK.

Questo sembra averlo risolto, i punti di interruzione ora vengono raggiunti come previsto. Penso che farlo insieme all'eliminazione delle cartelle bin e obj abbia aiutato la mia situazione.

In bocca al lupo!

So che questa è una vecchia domanda, ma ho avuto lo stesso problema e volevo postare qui nel caso in cui aiutasse qualcun altro. Ho un nuovo computer e il reparto IT ha unito il mio vecchio computer a quello nuovo. Quando ho configurato TFS, ho mappato un percorso locale diverso da quello che stavo utilizzando in precedenza, su un'unità interna aggiuntiva. Il vecchio percorso esisteva ancora dai dati uniti sul mio disco rigido, quindi potevo ancora creare ed eseguire. Anche i miei percorsi IIS puntavano alla vecchia directory. Dopo aver aggiornato IIS al percorso corretto, sono stato in grado di eseguire il debug correttamente. Ho anche cancellato la vecchia directory per buona misura.

L'ho provato anche io. Ho appena aperto la cartella obj sul progetto e quindi apro la cartella di debug, elimino il file .pdb e basta.

Questo errore si verifica anche se si tenta di apportare modifiche a un file di origine che non fa parte del progetto.

Stavo eseguendo il debug di un metodo da un .dll di un altro dei miei progetti, in cui Visual Studio aveva caricato in modo abbastanza utile il sorgente perché il .dll era stato compilato sulla stessa macchina e conosceva il percorso del sorgente. Ovviamente, la modifica di un file di questo tipo non farà nulla a meno che non si ricostruisca il progetto di riferimento.

1. Elimina tutti i punti di interruzione.
2. Ricostruire.
3. Fatto

In Visual Studio 2015, utilizzando C ++, ciò che ha risolto il the source file is different from when the module was builtproblema è stato per me

• riavviare Visual Studio.

Debug-> avvia senza eseguire il debug.

Questa opzione ha funzionato per me. Spero che questo ti aiuti!

Controlla se la posizione a cui hai puntato usando mex () in Matlab è corretta (contiene file lib e obj che sono stati modificati all'ultima data in cui hai compilato la libreria in Visual studio).

Se questo non è il caso:

Assicurati di compilare Visual Studio in una modalità che salva i file .lib:

1. proprietà -> Proprietà configurazione -> Generale -> Tipo di configurazione -> libreria statica

2. proprietà -> Proprietà configurazione -> Generale -> Estensione target = .lib (invece di exe)

Assicurati che l'output e le directory intermedie corrispondano alla directory Matlab in

1. proprietà -> Proprietà configurazione -> Generale -> Directory di output
2. proprietà -> Proprietà di configurazione -> Generale -> Directory intermedia

Nel mio caso, la risposta di @ Eliott non funziona. Per risolvere questo problema ho dovuto escludere / includere dal progetto il mio file difettoso, e anche pulire e ricostruire la soluzione.

Dopo queste azioni, il mio file con le mie ultime modifiche e il debugger vengono ripristinati.

Spero che questo aiuto.

Ho questo problema durante il debug a volte con Visual Studio ma quando l'applicazione è servita da IIS . (dobbiamo sviluppare in questa forma per alcuni motivi complicati che hanno a che fare con il modo in cui lo sviluppatore originale ha impostato questo progetto.)

Quando cambio il file e lo ricostruisco , spesso viene risolto. So che sembra sciocco, ma stavo solo cercando di eseguire il debug di un codice per vedere perché sta facendo qualcosa di strano quando non l'ho cambiato da un po ', e ho provato una dozzina di cose da questa pagina, ma è stato risolto semplicemente cambiando il file..