c# - visual - Al momento il punto di interruzione non verrà colpito. Nessun simbolo è stato caricato per questo documento in un'applicazione Silverlight




visual studio 2017 il punto di interruzione non verrà contato (20)

Ok, quello che ho:

Visual Studio 2010 RC, W7 x64, ha iniziato un nuovo tipo di progetto di applicazione Silverlight. Hosting dell'applicazione Silverlight in un progetto di applicazione Web ASP.NET. Silverlight versione 3.0. Aggiunta una classe LinqToSQL, un servizio WCF, un'applicazione Winform Tester (progetto nella soluzione) e alcune classi (anche come progetti nella soluzione).

Ieri, all'improvviso ho capito che "Il punto di interruzione non verrà colpito al momento. Nessun simbolo è stato caricato per questo documento. ' messaggio per apparire nell'IDE, ma riguarda solo l'applicazione Web, posso eseguire il debug di Silverlight e l'app Winform.

Quello che ho provato / ha fatto per sbarazzarmi del messaggio:

  • Reimposta le impostazioni di Visual Studio
  • rimosso tutti i file in ogni cartella \ Temporary ASP.NET Files (ce n'è uno per ogni 32 bit / 64 bit e per Framework 2.0 e 4.0)
  • ho provato a eseguire il debug utilizzando il server Web integrato di Visual Studio: normalmente utilizzo IIS, nell'output del progetto della soluzione ho eliminato tutte le cartelle obj e bin in ogni cartella del progetto
  • creato una nuova soluzione e aggiunto tutti i progetti a questa nuova soluzione
  • cancellato la soluzione suo file
  • ha creato una nuova applicazione Web ASP.NET per verificare se si tratta di un problema di installazione VS => È possibile eseguire il debug di questo nuovo progetto / soluzione
  • riavviato la macchina più volte
  • riparato l'installazione vs.
  • ha fatto un IISReset
  • rimosso l'app Web da IIS
  • utilizzato il pulsante Crea directory virtuale in Proprietà progetto dell'applicazione Web per creare una nuova app Web in IIS
  • cambiato la versione del framework di ogni progetto da 3.5 a 4.0
  • Aperta la soluzione sul mio secondo computer => stesso comportamento
  • ha scansionato Microsoft Connect per bug / problemi simili
  • SPESE 7 ORE.

Quindi, questo succede la seconda volta nella mia vita. l'ultima volta l'ho risolto eliminando la cartella temporanea di file ASP.NET, ma questa volta ho bisogno del tuo aiuto.


Aprire l'URL dell'applicazione Web dal browser e quindi nell'IDE di VS.Net utilizzare Strumenti -> AttachtoProcess

quindi collegare ad aspnet_wp.exe.

Il Debugger inizierà a funzionare


Assicurati di eseguire il programma in modalità DEBUG e non in modalità RELEASE.


Fare clic destro su soluzione -> Proprietà

Guarda sotto Proprietà comuni -> Progetto di avvio

Seleziona più progetti di avvio

seleziona Inizia azione sui progetti che devi eseguire il debug.


Goto Project Properties -> Build -> Avanzate ...

Nella sezione "Output" seleziona "full" nel menu a discesa Informazioni di debug


Ho avuto lo stesso problema e dopo aver cercato su google ho trovato due soluzioni tipiche per questo:

  1. Assicurati che il debugger di Silverlight sia attivato nel progetto .Web. Apri le proprietà del progetto e seleziona il debugger di Silverlight nella scheda "Web".

  2. Riavvia Visual Studio ed elimina tutte le cartelle bin e obj.

Ma nessuno di questi ha funzionato per me . Quindi qualcuno ha menzionato in fondo una discussione per provare a utilizzare IE come browser. Ciò ha reso il debug e i breakpoint di nuovo funzionanti!

Modificare:

Più tardi ho faticato con IE9 non funzionante, perché si attacca al processo sbagliato. Invece di attaccare manualmente al processo IE corretto ogni volta, ho trovato un trick chiaro:

  • Fai clic con il tasto destro su una delle pagine generate nel progetto .Web (.html o .aspx)
  • Fai clic su "Sfoglia con ..."
  • Imposta IE come browser predefinito (influenzerà solo la scelta del browser di Visual Studio)

Ora, Visual Studio avvierà IE quando esegue il progetto .Web e si collega al processo corretto. Questo dovrebbe farlo.


Ho avuto lo stesso problema ma in VS2013 per un'applicazione Web. Per me, la risposta era aggiornare la configurazione di build per la soluzione: -

  1. Fare clic con il tasto destro del mouse sulla soluzione e selezionare Proprietà
  2. Seleziona la configurazione di Debug
  3. Selezionare "Configurazione" in "Proprietà di configurazione" nel sottopentola
  4. Seleziona la casella "Crea" per ogni progetto che desideri eseguire il debug

Una volta che l'ho fatto, tutti i miei breakpoint hanno iniziato a funzionare.


Ho avuto lo stesso problema, stavo eseguendo il debug del mio progetto e ho dovuto fare clic con il tasto destro del mouse sul progetto e selezionare "nuova istanza di debug". Ho solo dovuto farlo una volta, poi ha funzionato normalmente.


Ho avuto lo stesso problema: ho perso molto tempo cercando di ottenere il debug lavorando in Visual Studio.

Finì per essere Nuget - Avevo 3 versioni di Newtonsoft.Json (su 7 progetti C #). La soluzione sarebbe stata compilata ma non era debuggabile.

Ho risolto il problema eseguendo quanto segue nella console di Gestione pacchetti di Nuget:

PM> Update-Package Newtonsoft.Json


Ho dovuto disinstallare manualmente tutte le istanze del file .dll dal registro e tutte le istanze del file .dll dalla mia unità locale. Disinstallato / reinstallato la mia app e ora sto colpendo i breakpoint! Ho sprecato mezza giornata facendo questo :(.


Ho provato a rinominare il file .pdb nella cartella obj\debug e ho fatto una soluzione pulita e ricostruita.
Ha creato un nuovo file .pdb e sono riuscito a centrare correttamente i breakpoint.


Il problema per me risultò essere che la casella di controllo Proprietà-> Build-> Ottimizza codice era stata attivata nella configurazione di Debug. Lo ha spento, ricostruito e il debug ha funzionato normalmente.


La ragione di ciò che hai dovuto affrontare è che i PDB ("PDB sta per Program Database, un formato di file proprietario (sviluppato da Microsoft) per la memorizzazione delle informazioni di debug su un programma) non sono aggiornati, questo potrebbe essere dovuto ad alcuni motivi :

1- Come ha detto Bevan, potresti eseguire il debug di un'altra applicazione!

2- Stai eseguendo il debug di un'altra versione della stessa applicazione. Ad esempio, hai allegato un'applicazione precedentemente costruita con la versione corrente del codice per il debug senza (ri) costruirla.

Pulizia o ricostruzione della soluzione risolve tali problemi per me.

Per assicurarti che il problema non sia tuo, prova a eseguire il debug della stessa applicazione con VS 2008 (temo possa essere un bug in VS 2010 - è ancora beta!).


Lo scenario è questo: un particolare progetto è il tuo progetto di avvio (ad es. Il metodo Main). Quel progetto fa riferimento ad altri progetti nella tua soluzione. I punti di rottura negli altri progetti non vengono colpiti.

Soluzione rapida: quando costruisci la tua soluzione, cerca nel percorso di output di Build (solitamente bin \ Debug) per il progetto di avvio. Guarda i file DLL e PDB per i progetti a cui stai facendo riferimento. Assicurati che la loro ultima data di modifica sia la data in cui hai creato l'ultima soluzione. In caso contrario, copiarli dal percorso di output Build per ciascun progetto nei progetti di avvio. Costruisci il percorso di output. Per esempio:

Progetto A ha Main. Fa riferimento a Progetto B. I punti di interruzione non vengono colpiti nel progetto B. Copiare il file DLL e PDB dal percorso di output Build del progetto B al percorso di output Build del progetto A. Quindi esegui la tua soluzione. Il punto di rottura sarà ora colpito.

Ora è necessario capire perché il progetto A non sta copiando il file DLL e il file PDB di Project B. Le risposte qui coprono la maggior parte degli scenari. Uno scenario che non viene toccato è assicurarsi che i progetti e la soluzione siano correttamente associati a TFS. Ho avuto alcuni progetti legati e alcuni non vincolati correttamente. Questo ha causato il problema per me. Una volta risolto, il problema è andato via e non ho più dovuto copiare i file DLL e PDB.


Ogni volta che ho riscontrato questo particolare errore, si è scoperto che la cartella in cui Visual Studio carica gli assembly è diversa dalla cartella in cui viene eseguita l'applicazione web.

Cioè, il server delle applicazioni esegue l'applicazione da

C:\dev\MyApplication\bin 

ma lo studio di Visual sta eseguendo il debug da

C:\dev\MyOtherApplication\bin (or something along those lines, anyway).

Nota: per vari motivi, eseguo il debugging con IIS come host dell'applicazione anziché il gizmo autonomo di dinky utilizzato dalla maggior parte delle persone. Questo potrebbe influenzare l'utilità della mia risposta!

Aggiornamento :

Per IIS, la directory del server delle applicazioni (ad esempio C:\dev\MyApplication precedente) è la directory fisica configurata per l'applicazione Web, che può essere controllata modificando le impostazioni di base per l'app.

Per Visual Studio la directory di debug (cioè C:\dev\MyOtherApplication precedente) è la directory in cui si trovano i file svc , solitamente la stessa directory del file di progetto csproj .


Per chi legge che utilizza Visual Studio 2008, non Visual Studio 2010 e riceve questo errore. Le risposte sopra non mi hanno aiutato in questa situazione, quindi sto condividendo la mia esperienza.

Se esegui il debug di un'applicazione Web IIS in Visual Studio 2008 collegandoti al processo w3wp.exe anziché utilizzare il server di sviluppo ASP.NET per il debug (inizia con il debug), questo potrebbe essere il tuo problema:

Visual Studio potrebbe fare ancora riferimento a un file di simboli (file utilizzato durante il debug) dalla tua DLL da un processo IIS non aggiornato. E quel file di simboli è stato ricreato da un codice sorgente .NET ricompilato, ma il processo IIS fa ancora riferimento al vecchio file di simboli.

Aggiustare:

Basta interrompere il debug in Visual Studio, riavviare l'applicazione Web e riconnettersi al processo. Quindi i punti di interruzione dovrebbero virare di nuovo dal giallo (quando vedi questo errore).

========================

Altre cose da provare (trovato nuova situazione oggi):

Ogni punto del collegamento sotto UNO ALLA VOLTA, ma ripeti i passaggi riportati di seguito con ognuno dei tentativi.

http://carnotaurus.philipcarney.com/post/4130422114/visual-studio-debugging-issue-with-files-of-the-same

1.) Arresta il debug (premi l'icona del quadrato rosso) in Visual Studio
2.) Soluzione pulita
3.) Soluzione Build
4.) [INSERIRE L'ISTRUZIONE DEL BULLET QUI]
5.) Strumenti> Collega a Processo (o inizia con il debug)
6.) Avvia il programma a cui stai collegando, ed eseguilo in modo tale che il tuo codice venga colpito

6 spiegato:

Se si esegue il collegamento a nunit.exe, aprire NUnit ed eseguire un test in modo da colpire il punto di interruzione

Se si collega a w3wp.exe (sito IIS), quindi aprire il sito nel browser e andare alla pagina che colpirà il punto di interruzione

MODIFICARE:

Oggi ho notato che se provi il debug su un progetto che non è impostato come progetto di avvio, lo mostrerà. Quando si allega al processo w3wp.exe, pensa al suo debug sul progetto impostato come progetto di avvio. Per risolvere, è sufficiente fare clic con il pulsante destro del mouse sul progetto di applicazione Web e scegliere "Imposta come progetto di avvio". Quindi prova a ricollegarti al tuo processo.


Per la mia app WPF, ho cancellato la cartella dell'applicazione, ho fatto "Get Latest" dal controllo del codice sorgente e ho ricostruito. Tutti i punti di interruzione funzionano alla grande ora.


Per risolvere questo problema in Web.config ho solo dovuto aggiungere debug="true"

  <system.web>
    <compilation targetFramework="4.0" debug="true">

Quello che mi ha aiutato a trovare questa soluzione è stato guardando le finestre dei Moduli durante il debug e ho visto che per le mie DLL ASP.NET caricate avevo: Binary non era stato costruito con le informazioni di debug.


Prova a impostare Silverlight Application Project come progetto di avvio: fai clic destro sul progetto -> 'Imposta come progetto di avvio. Quindi premere F5 e vedere se è possibile rilevare i punti di interruzione ...

Prova ad eliminare i dati di navigazione / temporanei nel tuo browser ogni volta che apporti modifiche all'applicazione Silverlight


Se esegui il debug di un progetto Web, assicurati che l'attributo debug = "true" sia stato impostato nel tuo file web.config:

<system.web>
    <compilation debug="true"   .../>

Un altro aneddoto che potrebbe essere utile-

Ho riscontrato questo problema quando uno dei miei progetti utilizzava i riferimenti di file da una cartella di output di rilascio. Quando i risultati della compilazione sono stati inseriti in una cartella Merci, queste DLL di rilascio sovrascrivevano le DLL di debug.

La soluzione era assicurarsi nel file csproj, il mio riferimento era HintPath

<HintPath>..\..\Core\Goods\$(Configuration)\MyFramework.dll</HintPath>

e non

<HintPath>..\..\Core\Goods\Release\MyFramework.dll</HintPath>





iis