Impossibile eseguire il breakpoint di bind - Visual Studio 2015

Ho appena eseguito l'aggiornamento da Visual Studio 2013 al 2015 e ora ho problemi con i punti di interruzione.

È un successo o un errore in cui i punti di interruzione funzioneranno effettivamente e se ne imposto uno durante il debug ottengo l'errore:

Impossibile interrompere il punto di interruzione.

Qualsiasi aiuto sarebbe apprezzato. Sono pronto per arrendermi nel 2015 e tornare indietro.

Ho avuto lo stesso problema ma una soluzione diversa. Si prega di notare che ho aggiornato a VS 2015 Update 1 e il problema è ancora presente.

Nella precedente edizione di VS il debug di avvio ha automaticamente attivato una build in modalità debug. Ma con VS2015 no.

Quindi, se l'ultima build era in modalità di rilascio e si tenta di eseguire il debug, il punto di interruzione non funzionerà.

Devi prima compilare manualmente in modalità debug, quindi avviare il debug.

Ho avuto lo stesso problema.

Ho risolto disabilitando l'opzione "Ottimizza codice" nella scheda Costruisci proprietà progetto.

Questo può sembrare banale, ma dopo un sacco di headcratching con gli stessi problemi che hai menzionato, ho scoperto che la mia build era impostata su "release" anziché "debug" quando ho provato a eseguire il debug .. ricostruendo la soluzione per "debug "risolto il problema e ho potuto impostare i punti di interruzione come di consueto

Ho avuto un problema simile con i punti di interruzione che non si associavano, nonché alcune variabili locali che non venivano valutate nella finestra Locali. Ciò che alla fine è stato risolto è stato abilitare l'opzione "Sopprima ottimizzazione JIT sul carico del modulo (solo gestito)" nella scheda Opzioni-> Debug-> Generale. Una volta ho impostato che era in grado di legare senza problemi.

Ho avuto questo problema Ho eseguito una sessione di profilazione delle prestazioni che ha modificato il Web.configfile con le impostazioni per il monitor delle prestazioni:

<appSettings>
   <add key="Microsoft.VisualStudio.Enterprise.AspNetHelper.VsInstrLocation" value="C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Team Tools\Performance Tools\vsinstr.exe"/>
</appSettings>


<compilation debug="true" targetFramework="4.5" 
      assemblyPostProcessorType="Microsoft.VisualStudio.Enterprise.Common.AspPerformanceInstrumenter, Microsoft.VisualStudio.Enterprise.AspNetHelper, Version=16.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
   ...
</compilation>


<runtime>
   <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
         <assemblyIdentity name="Microsoft.VisualStudio.Enterprise.AspNetHelper" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
         <codeBase version="16.0.0.0" href="file:///D:/Program%20Files%20(x86)/Microsoft%20Visual%20Studio/Shared/Common/VSPerfCollectionTools/vs2019/Microsoft.VisualStudio.Enterprise.AspNetHelper.DLL"/>
      </dependentAssembly>
      <dependentAssembly>
         <assemblyIdentity name="VsWebSite.Interop" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
         <codeBase version="8.0.0.0" href="file:///D:/Program%20Files%20(x86)/Microsoft%20Visual%20Studio/Shared/Common/VSPerfCollectionTools/vs2019/VsWebSite.Interop.DLL"/>
      </dependentAssembly>
   </assemblyBinding>
</runtime>

Questo ha rotto la mia capacità di fermarmi ai punti di interruzione. Quando sono tornato al Web.config originale (rimosso le impostazioni di Performance Profiler), i punti di interruzione hanno ripreso a funzionare.

Ho avuto lo stesso problema ieri. Ho usato la funzione "Soluzione pulita" e mi ha aiutato.

la soluzione è disabilitare l'ottimizzazione del design.

Project Properties> Build> Advanced Compile Options> Enable Optimizations

Eseguo prestazioni sulla mia soluzione e ciò ha aggiunto questo al mio web.config

<compilation debug="true" targetFramework="4.5" assemblyPostProcessorType="Microsoft.VisualStudio.Enterprise.Common.AspPerformanceInstrumenter, Microsoft.VisualStudio.Enterprise.AspNetHelper, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/> 

il assemblyPostProcessorTypeè il problema, ho cancellato e che risolto il mio problema

Cambia la modalità di rilascio in Debug, nel mio caso, questo ha risolto il mio problema.

Non ho modificato l'impostazione "Ottimizza", ma in base ad altre risposte qui

1. Impostare Esplora soluzioni su Mostra tutti i file per il progetto
2. Eliminato il cestino nascosto e le cartelle di debug
3. Eseguito un 'Clean' sul progetto
4. Eseguito 'Ricostruisci' sul progetto

Finora questo mi ha risolto il problema. Sembra che l'aggiornamento a VS2015 Update 2 abbia corretto alcune cose sul mio sistema.

So che questo è un vecchio post, ma nel caso in cui tutti gli altri trucchi sopra non funzionino per te assicurati che l'immagine che stai cercando di eseguire il debug sia attuale. Per qualche motivo, dopo aver pubblicato e trasferito un progetto .NET Core sul mio Raspberry Pi, "decomprimere" su RPi non stava copiando e sovrascrivendo alcune DLL nella directory di lavoro. Quando ho collegato il debugger pensando che tutto fosse a posto, alcuni punti di interruzione venivano colpiti, altri no e alcuni altri mi davano l'errore "impossibile da associare". Una volta risolto il problema di decompressione, tutti i miei punti di interruzione e simboli sono tornati. Spero che aiuti.

Oggi ho riscontrato gli errori di breakpoint vincolanti. E ho risolto il mio problema facendo belows.

Se tutte le configurazioni di debug non sono corrette, non è possibile risolvere il problema facendo belows.

1. Progetto pulito
2. Se il percorso di output è diverso dalla cartella bin, sostituirlo nella cartella bin (questa è la regola più importante)
3. Ricostruire

Forse questa soluzione aiuta qualcuno.

I punti di interruzione VS non possono essere associati a metodi asincroni.

Avevo installato un agente App Dynamics che ha causato questo. Rimuovilo e sei a posto.

Ho avuto lo stesso problema, ma non avevo capito che "Debug" era cambiato in "Release" sulla barra degli strumenti di debug (di solito direttamente sotto il menu). Quindi l'ho impostato su "Debug" ha funzionato.

Il nuovo aggiornamento per Microsoft Visual Studio 2015 Update 3 (KB3165756) ha risolto il problema del punto di interruzione per me in cui sto cercando di ispezionare le variabili locali nel codice C # incorporato nei file cshtml nelle applicazioni ASP.NET Core.

PASSAGGIO 1, Escludere l'ovvio:

• Compilare in modalità debug.
• Prova a pulire la soluzione prima di impostare il punto di interruzione.
• Vai alla cartella Debug ed elimina il file .pdb [La tua applicazione].
• Quindi crea o ricostruisci la tua applicazione.
• Vai alla cartella Debug e conferma di avere un nuovo file .pdb [La tua applicazione].
• Quindi prova a impostare il punto di interruzione.

PASSAGGIO 2 Per i progetti C ++:

Controllare le seguenti proprietà del progetto:

• Formato informazioni C ++ / Generale / Debug: Database del programma.
• C ++ / Ottimizzazione: disabilitato.
• C ++ / Generazione di codice / Libreria di runtime: debug multi-thread.
• Linker / Debug / Genera informazioni di debug: Sì.
• Linker / Debugging / Genera database del programma: $ (TargetDir) $ (TargetName) .pdb.
• Linker / File manifest / Genera manifest: No.
• Linker / File manifest / Consenti isolamento: No.
• Linker / IDL incorporato / Ignora IDL incorporato: Sì.

• Ripeti il ​​passaggio 1

  Puoi provare ad aggiungere __debugbreak (). Questa affermazione deve essere inserita nel file sorgente in cui si desidera interrompere.

PASSAGGIO 2 Per i progetti C #:

• Nelle proprietà del progetto il codice Build / General / Optimize dovrebbe essere disabilitato.
• Nelle impostazioni IDE Debug / Opzioni e impostazioni / Debug / Soppressione generale Ottimizzazione JIT al caricamento del modulo (solo gestito): abilitato
• Ripeti il ​​passaggio 1

Prova ad aprire la tua soluzione su un altro computer. Se riesci a associare un breakpoint su una macchina diversa, ciò può significare che c'è un problema con il tuo VS o il tuo sistema operativo.

PASSAGGIO 3, assicurati che il tuo VS sia aggiornato:

Sono stati segnalati problemi come questo in VS2013 RTM, VS2015 Update 1 e Update2.

In VS vai su Strumenti / Estensioni e aggiornamenti / Aggiornamenti / Aggiornamenti del prodotto e vedi quale versione stai utilizzando. Se è necessario un aggiornamento, verrà visualizzato lì.

PASSAGGIO 4, assicurati che il tuo sistema operativo sia aggiornato:

Infine, se si esegue un sistema operativo Win 10, è stato segnalato un bug relativo a questo problema che esisteva nella build 14251. Questo problema è stato risolto nella build 14257 (e successive).

Ho appena incontrato un problema simile e nessuna delle risposte qui ha colpito il problema che stavo affrontando. A differenza della domanda, tuttavia, non ricevo mai alcun messaggio che affermi che non è stato possibile vincolare. Il punto di interruzione non colpisce mai. Spero che questo sia utile per qualcuno in futuro sbattere la testa sul muro con WCF.

TL / DR:
nel messaggio SOAP era presente un record con dati errati che impediva al punto di interruzione di essere colpito.

La storia completa:

Ho un servizio WCF basato su WSDL di un altro team. Non la mia definizione, nessun controllo su di essa ... Ricevo messaggi da questo altro team attraverso questo servizio. Nel mio caso ricevo messaggi, posso registrare il messaggio nella tabella di registro dei messaggi nel database (cosa che accade prima che il mio metodo di servizio venga chiamato), il metodo di servizio sembra essere chiamato (forse non lo è) e il server risponde con un 202 accettato. La comunicazione funziona, tranne per il fatto che nessun dato viene salvato nel database durante la chiamata del metodo.

Poiché il servizio restituisce una risposta positiva, ho escluso i problemi relativi a http e trasporto.

Quindi ho avviato VS2015 per eseguire il debug del servizio. Il messaggio in questione è ampio ma rientra nei limiti di ciò che mi aspetterei. Ho inserito un punto di interruzione nella prima riga del metodo di servizio e ho inviato il messaggio di grandi dimensioni, ma il punto di interruzione non ha mai raggiunto. Ho provato un messaggio più piccolo che sapevo funzionare sulla stessa istanza di esecuzione e il punto di interruzione è stato colpito bene. Quindi tutto nella configurazione sembrava a posto. Ho pensato che forse c'era qualcosa nella dimensione del messaggio.

Ho provato tutto ciò che sono riuscito a trovare, assicurandomi di trovarmi in una configurazione di debug, pulito e ricostruito, collegando manualmente il debugger al processo w3wp (come già VS), usando al Debugger.Break()posto di un breakpoint, impostando più progetti di avvio, scaricando il mio progetto di test in modo che il progetto di servizio fosse l'unico, aggiornando .NET, riavviando VS2015, riavviando, passando da IIS locale a IIS Express e viceversa, ricreando il servizio con l'ultimo WSDL garantito. Nulla importava. Il breakpoint non è mai stato raggiunto.

Ho finito per dover cancellare i record nel messaggio grande uno per uno fino a quando ho trovato un singolo record con dati errati. Nel mio caso era un record che non aveva valore per 2 campi DateTime. Quando ho creato un messaggio che conteneva solo questo record e l'ho inviato, il punto di interruzione non è stato colpito. Quando ho fornito i valori per quei 2 campi DateTime e ho inviato lo stesso messaggio (fisso) nel punto di interruzione attivato come previsto.

Avevo abilitato ogni singola eccezione CLR, nulla veniva generato a parte i file .pbd mancanti, di cui non mi importava. WCF ha inviato felicemente la richiesta con un record negativo. Non sto dicendo che WCF non avrebbe dovuto inviarlo in base ai contratti, solo che il cattivo record non ha causato il breakpoint.

Ho dovuto modificare il file web.config per abilitare il debug. Cambia questo:

<compilation debug="true" targetFramework="4.5.2" assemblyPostProcessorType="Microsoft.VisualStudio.Enterprise.Common.AspPerformanceInstrumenter, Microsoft.VisualStudio.Enterprise.AspNetHelper, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>

per:

<compilation debug="true"/>

Pulisci l'intera soluzione prima di provare una delle altre soluzioni. Dopo aver provato quasi tutto il resto nelle risposte precedenti e aver riavviato più volte Visual Studio, è bastato pulire la soluzione!

Ho provato tutto qui suggerito. Alla fine, ho impostato la "Pagina specifica" in Proprietà progetto -> Web sul mio URL di avvio locale, sulla pagina e sul parametro della query. Ha fatto una pulizia e ricostruzione in modalità debug e ha colpito il mio punto di interruzione.

Mentre questa è una build molto più tardi (VS2017) ho avuto questo problema con i progetti C #. Ho provato a pulire, ricostruire, riavviare Visual Studio, ecc.

Ciò che risolveva stava chiudendo Visual Studio ed eliminando la cartella .vs, che è una cartella nascosta situata nella directory della soluzione. L'eliminazione della cartella .vs non dovrebbe causare alcun problema, sebbene sia necessario ripristinare il progetto di avvio.

Nel mio caso, c'era un nuovo file web.config creato dopo l'uso Profiler. Ripristino web.config alla versione precedente, risolto questo problema. Era un'applicazione web VS2015 C #.

Nel caso in cui si stia pubblicando il controllo dell'applicazione Web Configurationimpostato su Debug(per impostazione predefinita, la configurazione del debug è impostata in modo tale che il codice non sia ottimizzato e la tabella dei simboli sia completamente creata).

Ho esaminato le risposte precedenti e la risposta di @ Will ha risolto il problema principale che stavo riscontrando, l'altro è stato in grado di modificare e continuare, ma dando un'occhiata più da vicino al file AssemblyInfo.cs ho scoperto alcune funzionalità di debug in cui disabilitato.

Poi ho finito per rimuovere i vecchi attributi di debug e aggiungere quanto segue che ho preso da un altro progetto

#if DEBUG
[assembly: System.Diagnostics.Debuggable(System.Diagnostics.DebuggableAttribute.DebuggingModes.DisableOptimizations | System.Diagnostics.DebuggableAttribute.DebuggingModes.EnableEditAndContinue | System.Diagnostics.DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints | System.Diagnostics.DebuggableAttribute.DebuggingModes.Default)]
#endif

Eppure penso che questo non sia il modo migliore per farlo.