Ok, quello che ho:

Visual Studio 2010 RC, W7 x64, ha avviato 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 ottenuto "Il punto di interruzione non sarà attualmente colpito. Nessun simbolo è stato caricato per questo documento. " messaggio da visualizzare nell'IDE, ma riguarda solo l'applicazione Web, posso eseguire il debug di Silverlight e l'app Winform.

Cosa ho provato / fatto per sbarazzarmi del messaggio:

• Ripristina impostazioni di Visual Studio
• rimosso tutti i file in ogni cartella \ File temporanei ASP.NET (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
• ha creato una nuova soluzione e ha aggiunto tutti i progetti a questa nuova soluzione
• eliminato il file soluzione suo
• creato una nuova applicazione Web ASP.NET per verificare se si tratta di un problema di installazione VS => Posso eseguire il debug di questo nuovo progetto / soluzione
• riavviato la macchina più volte
• riparato l'installazione di vs.net
• fatto un IISReset
• rimossa l'app Web da IIS
• utilizzato il pulsante Crea directory virtuale in Proprietà progetto dell'app Web per creare una nuova app Web in IIS
• ha cambiato la versione quadro di ogni progetto da 3.5 a 4.0
• Ho aperto la soluzione sulla mia seconda macchina => stesso comportamento
• scansione di Microsoft Connect per bug / problemi simili
• Trascorso 7 ore.

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

Fare clic con il tasto destro sulla soluzione -> Proprietà

Cerca in Proprietà comuni -> Progetto di avvio

Seleziona più progetti di avvio

selezionare Avvia azione sui progetti di cui è necessario eseguire il debug.

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

1. Assicurarsi che il debugger Silverlight sia attivato nel progetto .Web. Aprire le proprietà del progetto e selezionare il debugger 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 citato un thread in fondo per provare invece a utilizzare IE come browser. Ciò ha reso di nuovo debug e punti di interruzione funzionanti!

Modificare:

Più tardi ho lottato con IE9 non funzionante, perché si collega al processo sbagliato. Invece di collegarmi manualmente al processo IE corretto ogni volta, ho trovato un trucco pulito :

• Fare clic con il pulsante destro del mouse su una delle pagine generate nel progetto .Web (.html o .aspx)
• Fai clic su "Sfoglia con ..."
• Imposta IE come browser predefinito (influirà solo sulla scelta del browser Visual Studio)

Ora, Visual Studio avvierà IE durante l'esecuzione del progetto .Web e si collegherà al processo corretto. Questo dovrebbe farlo.

Ogni volta che ho riscontrato questo particolare errore, si è scoperto che la cartella da cui Visual Studio sta caricando gli assembly è diversa dalla cartella da cui è in esecuzione l'applicazione Web.

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

C:\dev\MyApplication\bin 

ma Visual Studio sta eseguendo il debug da

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

Nota: per vari motivi, eseguo il debug con IIS come host dell'applicazione anziché con il gizmo standalone dinky che la maggior parte delle persone usa. Ciò potrebbe influenzare l'utilità della mia risposta!

Aggiornamento :

Per IIS la directory del server delle applicazioni (ovvero C:\dev\MyApplicationsopra) è 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 (ovvero C:\dev\MyOtherApplicationsopra) è la directory in cui svcsi trovano i file, in genere la stessa directory del csprojfile di progetto.

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

Il motivo 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, ciò 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, è stata allegata un'applicazione precedentemente creata con la versione corrente del codice per il debug senza (ri) costruirla.

La pulizia o la 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 che possa essere un bug in VS 2010 - è ancora beta!).

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

Questo errore si ripresenta ogni tanto per me e posso sempre risalire alle impostazioni del progetto per l'assemblaggio in questione. Non è necessario "attendere" fino a quando il codice non riesce a rispettare un punto di interruzione o fino a quando non si imposta il punto di interruzione, per sapere quali assembly hanno simboli caricati.

Quando si esegue un progetto in modalità debug, nella finestra Output verranno elencati gli assembly con simboli caricati come di seguito (potrebbe essere necessario aprire l'immagine in una nuova scheda): T

Quindi in questo caso BASD.Core.Data.dll NON ha simboli caricati. Quindi puoi confrontare le impostazioni del progetto per questo assembly con quelle di un altro assembly che è riuscito a caricare i simboli, al fine di capire perché alcuni lo fanno e altri non caricano i simboli.

"Per me", tuttavia, "ogni" volta che ciò accade è perché le informazioni di debug non vengono create. Quindi apro Proprietà progetto> Genera> Avanzate in un progetto (C #).

Quindi per Basd.Core.Data.dll sopra cioè nessun simbolo le impostazioni di build avanzate erano:

Considerando che per Basd.Core.Configuration.dll cioè un assembly in cui ho potuto impostare e colpire un breakpoint le impostazioni erano:

Quindi sto fornendo informazioni di debug in quest'ultimo progetto e non nel primo, quindi la mia capacità di raggiungere il punto di interruzione in Basd.Core.Configuration.dll

Si noti inoltre che non è sufficiente avere semplicemente un file .pdb nella cartella bin di un progetto per un determinato .dll perché potrebbe non essere aggiornato e quindi non essere raccolto da Visual Studio come file di simboli valido per il .dll stai provando a passare.

Inoltre, la modifica delle configurazioni della build può modificare le impostazioni delle informazioni sulla build e la posizione da cui vengono estratti i simboli.

(Mi rendo conto che in questo caso sono in modalità Rilascio ma il metodo si applica ancora)

Vai a Proprietà progetto -> Crea -> Avanzate ...

Nella sezione "Output" seleziona "completo" nel menu a discesa Informazioni debug

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

Debug -> Collega al processo ->
scegli Debug questi tipi di codice: opzione ->
seleziona Managed v3.5, v3.0, v2.0 o Managed v4.5, v4.0

Ho appena risolto questo problema in base alla distribuzione di applicazioni Silverlight . (Questa risposta è un duplicato di alcuni altri, ma cercherò di spiegarlo più approfonditamente.)

È molto probabile che il problema sia che l'applicazione Silverlight non venga distribuita correttamente nell'applicazione Web al momento della creazione / avvio. Questo è un problema di riferimento: è semplice da capire ma non ovvio la prima volta che lo incontri.

Proprio come qualsiasi altro riferimento al progetto, l'output del progetto referenziato deve essere copiato nella cartella bin del progetto referenziato per eseguire il debug. Per le librerie di classe questo accade quando si fa clic con il tasto destro e si seleziona "Aggiungi riferimento ...". Per Silverlight, è necessario aggiungere un riferimento tramite Proprietà progetto.

• Fare clic con il tasto destro del mouse sul progetto e selezionare "Proprietà"
• Seleziona la scheda "Applicazioni Silverlight" a sinistra
• Premi il pulsante 'Aggiungi ...' e seleziona il tuo progetto Silverlight dalla finestra di dialogo

Ciò aggiunge un riferimento all'applicazione Silverlight dall'app Web di hosting e garantisce che il xapfile verrà copiato nell'app Web durante la compilazione o la distribuzione. Ciò significa che l'app Silverlight corrente e i relativi file di debug si trovano all'interno dell'applicazione in fase di debug e sarai in grado di scorrere il codice.

Se stai eseguendo 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"   .../>

Ho avuto lo stesso problema su Windows 7 e ho provato di tutto : DLL pulite, elenco dei moduli esaminati, disattivato "Just My Code" e così via.

Il problema è stato risolto dopo che ho eseguito Visual Studio "come amministratore". Onestamente. Perché Microsoft non ha potuto semplicemente avvisarmi che non è in esecuzione "come amministratore"? Mi risparmierebbe qualche ora di lavoro.

Per me il problema era che avevo attivato "Ottimizza codice" nella scheda Costruisci delle impostazioni del mio progetto.

Ho avuto lo stesso problema

Per qualche motivo, una delle DLL era registrata nel GAC, quindi aveva sempre una versione diversa rispetto al codice.

Una volta rimosso dal GAC, il problema è stato risolto

Per coloro che leggono Visual Studio 2008, non Visual Studio 2010 e visualizzano questo errore. Le risposte sopra non mi hanno aiutato in questa situazione, quindi sto condividendo la mia esperienza.

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

Visual Studio potrebbe ancora fare riferimento a un file di simboli (file utilizzato durante il debug) dalla DLL da un processo IIS non aggiornato. E quel file di simboli è stato ricreato da una ricompilazione del codice sorgente .NET 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 ricollegarsi al processo. Quindi i punti di interruzione dovrebbero passare dal giallo (quando viene visualizzato questo errore) al rosso.

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

Altre cose da provare (ho trovato una nuova situazione oggi):

Esegui tutti i punti elenco nel link sottostante UNO ALLA VOLTA, ma ripeti i miei passaggi di seguito con ognuno di essi.

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

1.) Interrompere il debug (premere l'icona quadrata rossa) in Visual Studio
2.) Clean Solution
3.) Build Solution
4.) [INSERIRE ISTRUZIONI BULLET QUI]
5.) Strumenti> Collega al processo (o iniziare con il debug)
6.) Avvia il programma a cui ti stai collegando ed eseguilo in modo che il tuo codice venga colpito

6 ha spiegato:

Se si collega a nunit.exe, quindi aprire NUnit ed eseguire un test in modo che il punto di interruzione venga colpito

Se ti colleghi a w3wp.exe (sito IIS), apri il tuo sito nel browser e vai alla pagina che colpirà il tuo breakpoint

MODIFICARE:

Oggi ho notato che se provi a eseguire il debug su un progetto che non è impostato come progetto di avvio, verrà mostrato. Quando si collega al processo w3wp.exe, viene considerato il debug sul progetto impostato come progetto di avvio. Per risolvere, fai clic con il pulsante destro del mouse sul progetto dell'applicazione Web e scegli "Imposta come progetto di avvio". Quindi prova a ricollegarti al processo.

Lo scenario è questo: un particolare progetto è il tuo progetto di avvio (ad esempio ha il metodo principale). Quel progetto fa riferimento ad altri progetti nella tua soluzione. I punti di interruzione negli altri progetti non vengono colpiti.

Soluzione rapida: quando crei la tua soluzione, cerca il progetto di avvio nel percorso di output Build (in genere bin \ Debug). Guarda i file DLL e PDB per i progetti a cui fai riferimento. Assicurarsi che la data dell'ultima modifica sia la data dell'ultima creazione della soluzione. In caso contrario, copiarli dal percorso di output Build per ciascun progetto nei progetti di avvio Percorso di output Build. Per esempio:

Il progetto A ha principale. Fa riferimento al Progetto B. I tuoi punti di interruzione non vengono raggiunti nel Progetto B. Copia il file DLL e PDB dal percorso di output Build del Progetto B nel percorso di output Build del Progetto A. Quindi esegui la tua soluzione. Il punto di interruzione verrà ora colpito.

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

Le soluzioni allo stesso problema nel mio caso erano le seguenti combinazioni di passaggi:

1. Soluzione -> Proprietà Seleziona più progetti di avvio seleziona Avvia azione sui progetti che devi eseguire il debug.
2. Rimosso il servizio dai riferimenti di servizio e ripulito la soluzione.
3. Ricostruire il progetto di servizio
4. Aggiunto di nuovo ai riferimenti di servizio
5. Pulisci la soluzione e ricostruiscila.

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

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

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

Ho avuto lo stesso problema ma in VS2013 per un'app Web. Per me, la risposta è stata aggiornare la configurazione della 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 ciascun progetto di cui desideri eseguire il debug

Una volta fatto questo, tutti i miei punti di interruzione hanno iniziato a funzionare.

Ok, eccoci:

(In una "app silverlight": per prima cosa controlla che silverlight sia selezionato in "web" nelle "proprietà" del progetto del tuo server - Se ciò non lo ha risolto, prova questo sotto)

Al primo tentativo: esegui prima questo: devenv.exe / ResetSettings e 1: nel menu in alto, fai clic sul tag di debug 2: fai clic su opzioni e impostazioni 3: in "debug" e in "generale" trova "abilita stepping sorgente .net framework" 4: selezionare la casella. 5: E ora tutti i simboli verranno scaricati e riconfigurati :)

Se succede di nuovo dopo quanto sopra, cancella semplicemente la cartella in cui si trovano i simboli:

1: Nel menu in alto, fai clic sul tag di debug 2: fai clic su opzioni e impostazioni 3: In "debug" e sotto "simboli" trova il pulsante "svuota cache dei simboli" e fai clic su di esso.

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

quindi collegare a aspnet_wp.exe.

Il debugger inizierà a funzionare

Ho dovuto disinstallare manualmente tutte le istanze del .dll dal registro e tutte le istanze del .dll dal mio disco locale. Ho disinstallato / reinstallato la mia app e ora sto colpendo i punti di interruzione! Ho perso mezza giornata facendo questo :(.

Ho provato a rinominare il .pdbfile nella obj\debugcartella e ho fatto una soluzione pulita e ricostruire.
Ha creato un nuovo .pdbfile e sono stato in grado di raggiungere correttamente i punti di interruzione.

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

Alla fine è stato Nuget: avevo 3 versioni di Newtonsoft.Json (in 7 progetti C #). La soluzione si sarebbe compilata ma non era debuggabile.

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

PM> Pacchetto di aggiornamento Newtonsoft.Json

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

Prova a impostare Silverlight Application Project come progetto di avvio: fai clic con il pulsante destro del mouse sul progetto -> 'Imposta come progetto di avvio. Quindi premi F5 e vedi se riesci a catturare i punti di interruzione ...

Prova a eliminare i dati di navigazione / temp nel tuo browser ogni volta che apporti modifiche all'applicazione silverlight

Un altro aneddoto che potrebbe essere utile-

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

La soluzione era assicurarsi che nel file csproj, HintPath del mio riferimento fosse

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

e non

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

Ho avuto questo stesso problema quando in un client dove - per ogni soluzione applicativa - hanno copiato la maggior parte degli assembly condivisi in una cartella " Riferimenti ", quindi li hanno aggiunti alla soluzione sia come " Elementi soluzione " che come " Progetto " all'interno della soluzione.

Non sono ancora sicuro del perché, ma alcuni di essi erano debuggabili, altri no, anche se nelle impostazioni Riferimenti per gli assiemi sono stati specificati i percorsi completi corretti.

Questo comportamento imprevedibile mi ha fatto impazzire :)

Ho risolto questo problema rimuovendo tutti gli assembly dalla cartella " Riferimenti " per i quali c'erano progetti con codice sorgente e mantenendo un'ottima traccia delle informazioni sulla versione per gli assembly condivisi.

Ho avuto un problema simile, tranne per il fatto che il mio problema era sciocco: avevo 2 istanze del web server integrato in esecuzione su 2 porte diverse E avevo il mio progetto -> proprietà -> web -> "Avvia URL" che punta a una porta fissa ma l'app Web non era effettivamente in esecuzione sotto quella porta. Quindi il mio browser veniva reindirizzato all '"URL di avvio" che si riferiva al 1539 ma l'istanza di codice / debug era in esecuzione sulla porta 50803.

Ho modificato il server Web incorporato per l'esecuzione in una porta fissa e ho modificato il mio "URL di avvio" per utilizzare anche quella porta. progetto -> proprietà -> web -> sezione "Server" -> "Usa Visual Studio Development Server" -> porta specifica