.net - stato - visual studio 2017 il punto di interruzione non verrà contato




"Il punto di interruzione non verrà colpito al momento. Il codice sorgente è diverso dalla versione originale. "Che cosa significa? (20)

Quando eseguo il debug in Visual Studio, a volte aggiungo un punto di interruzione ma è vuoto e VS dice "Il punto di interruzione non verrà colpito al momento, il codice sorgente è diverso dalla versione originale." Ovviamente questo mi impedisce di essere in grado di eseguire il debug.

Cosa diavolo significa il messaggio? Quale versione originale? Se ho appena aperto la soluzione e non ho apportato alcuna modifica al codice, come può esserci una "versione originale"?


È possibile ottenere questo messaggio quando si utilizza un attivatore e l'assembly in cui è stato impostato il punto di interruzione non è stato ancora caricato.

Il punto di interruzione si risolverà una volta che l'attivatore carica l'assieme (supponendo che i simboli dell'assieme e del debug siano aggiornati). Un buon posto per guardare è la finestra dei moduli nel menu di debug. Lì dovresti cercare l'assembly a cui appartiene anche il tuo file. Innanzitutto controlla che l'assembly sia caricato. Quindi, da dove viene caricato? Quindi, viene caricato il file dei simboli. Di nuovo, da dove viene caricato il file dei simboli? Infine controlla le versioni di entrambi.


C'è un'impostazione quasi impercettibile che ha risolto questo problema per me. Se c'è un particolare file sorgente in cui il punto di interruzione non sta colpendo, potrebbe essere elencato in

  • Esploratore di soluzioni
    • tasto destro del mouse su Soluzione
      • Proprietà
        • Proprietà comuni
          • Esegui il debug dei file sorgente
            • "Non cercare questi file sorgente".

Per qualche ragione a me sconosciuta, VS 2013 ha deciso di collocare un file sorgente lì, e successivamente, non ho più potuto raggiungere il breakpoint in quel file. Questo potrebbe essere il colpevole per "il codice sorgente è diverso dalla versione originale".


Ciò accade anche durante il debug di un progetto C ++ che carica un modulo che è stato implementato con un linguaggio CRL (Managed C ++, C # etc). In questa situazione il messaggio di errore è davvero fuorviante.

La soluzione consiste nel mettere la proprietà di configurazione del supporto Common Language Runtime (CLR) al progetto di avvio e ricompilarlo.


Ciò che ha funzionato per me è stato quello di cambiare la piattaforma della soluzione da x86 a qualsiasi CPU. Dopo aver cambiato Any, ho impostato un indirizzo di stop, ho eseguito il sito web, aperto la pagina, ho fatto clic sul pulsante e si è fermato. Ho chiuso il sito, cambiato di nuovo in x86 ed eseguito la stessa sequenza con successo.


Ciò si verifica spesso anche se si utilizzano i riferimenti di file ai binari (anziché i riferimenti di progetto al codice nel progetto) e il binario compilato a cui si fa riferimento non è sincronizzato con il codice sorgente corrispondente sulla macchina. Questo può accadere perché hai scaricato una nuova versione del file binario dal controllo del codice sorgente senza il nuovo codice sorgente, oppure hai qualche versione del file binario sul tuo computer e fai riferimento a una vecchia copia, ecc. Se questo è davvero il problema, è una buona ragione per usare i riferimenti ai progetti tanto quanto è pratico.


Come si dice, il "codice sorgente è diverso dalla versione originale".

Fare clic con il tasto destro del mouse sulla cartella del progetto all'interno di Solution Explorer e scegliere Clean . Costruisci una nuova versione del progetto e il breakpoint funzionerà di nuovo!


Hai mai fatto questo?

Vorresti continuare ed eseguire l'ultima build di successo?

Se si è spuntata la casella e si è premuto "Sì", si otterrà l'ultima esecuzione riuscita anche se il progetto non viene compilato. Ciò significa che ogni volta che si imposta un punto di interruzione, si otterrà quell'errore.

Prova a cambiare questo valore:

  • Utensili
    • Opzioni
      • Progetti e soluzioni
        • Costruisci ed esegui
          • In Esecuzione, quando si verificano errori di generazione o distribuzione: Non avviare

Ho avuto lo stesso problema in diversi progetti in un progetto di architettura a più livelli e il problema era nelle configurazioni che la casella di controllo per il progetto selezionato non è stata verificata. quindi il problema è stato risolto per un progetto.

Per un altro livello stava dando lo stesso problema anche se la build è abilitata nelle configurazioni. Ho fatto tutte le altre opzioni come riavviare la pulizia del progetto, ma non sono state di aiuto. Alla fine ho deselezionato la casella di controllo build per quel particolare progetto e pulito e ricostruito. di nuovo ha segnato la casella di controllo e ha fatto lo stesso. quindi il problema è stato risolto.

Spero che questo ti aiuti..


Il problema è che le tue informazioni di debug non sono sincronizzate con il tuo assembly. La soluzione è semplice:

  1. Vai alla tua cartella bin
  2. Rimuovere i file .pdb
  3. Ricostruire

Dovrebbe fare il trucco!

(la cosa strana è che una ricostruzione senza buttare via i file .pdb non sempre funziona. Posso vedere la data di modifica che viene aggiornata, ma ancora da qualche parte nella catena (VS2013 debugger, IIS, cache di assembly) questa modifica non viene rilevata )


In Windows 7, Visual Studio Express 2010, se è stata attivata l'opzione Usa la modalità di compatibilità per Windows XP SP3 , è possibile che si verifichi questo errore.

Ho deselezionato l'opzione e ha funzionato di nuovo perfetto. Fare clic con il tasto destro sul collegamento a VS o all'eseguibile, selezionare Proprietà e quindi compatibilità .


Nel mio caso, stavo collegandomi a un processo in esecuzione in VS 2012. Durante il collegamento, ti viene data l'opzione di eseguire il debug in varie modalità (nativo, script, silverlight, gestito 2.0, gestito 4.0, ecc.). Per impostazione predefinita, il debugger seleziona automaticamente la modalità. Tuttavia, Automatico non sempre fa la scelta giusta. Se il tuo processo contiene più tipi di codice, assicurati che il debugger stia utilizzando quello corretto.


Nel mio caso, stavo sviluppando un'applicazione per Windows CE, testata contro un emulatore. Il problema era che l'eseguibile non era distribuito all'emulatore, quindi il file .pdb (nell'ambiente di sviluppo) non era sincronizzato con l'exe (nell'emulatore), perché il nuovo exe non veniva mai copiato nell'emulatore. Ho dovuto eliminare l'exe nell'emulatore per forzare una nuova distribuzione. Quindi ha funzionato.


Per me la soluzione era nascosta nelle Advanced Build Settings delle proprietà del progetto:

Per un motivo sconosciuto è stato impostato su none : impostandolo su full causato il breakpoint da colpire.

Per accedere a questa finestra di dialogo, apri le proprietà del progetto, quindi vai a Build , quindi seleziona il pulsante Advanced... nella parte inferiore della pagina.


Per me, nessuno degli articoli ha risolto il problema. Ho appena aggiunto una nuova riga di codice all'interno di quella funzione, qualcosa del tipo:

int a=0;

aggiungendo questo, credo di aver attivato lo studio visivo per aggiungere questa funzione alla versione originale


Prestare attenzione alla finestra "Output" in VS. Ti dirà quali sono gli assembly caricati e quando. È possibile che venga caricata una versione precedente dell'assieme da qualche parte nella cartella.

Ad esempio, se si dispone di più assiemi e si sta tentando di interrompere in uno degli assiemi di supporto, il CLR gestirà la risoluzione dell'assieme, che potrebbe caricare un altro file di assieme rispetto a quello a cui si è fatto riferimento nel progetto.


Prova a disabilitare e reimpostare il punto di interruzione durante l'esecuzione in modalità di debug invece di farlo prima di avviare la modalità di debug.


Se il tuo processo di debug contiene più appdomain e l'assembly è caricato in entrambi, e uno di questi sta caricando una vecchia copia (di solito qualcosa caricato dinamicamente come un plugin) il punto di interruzione può apparire solido, ma il thread che dovrebbe raggiungere il breakpoint è nel Appdomain con il vecchio assembly, e non colpisce mai. Puoi vedere quali sono gli assembly caricati e il loro percorso nella finestra del modulo.


Seleziona Debug in Solution Configurations , anziché Release


Vai a

  • Utensili
    • Opzioni
      • Debug
        • Generale

Deselezionare Richiedi file di origine per far corrispondere esattamente la versione originale


vai a:

Strumenti> Opzioni> Debug> Generale> deselezionata " Richiede i file di origine esattamente corrispondenti alla versione originale "







debugging