VS2012 - Perché il mio thread principale dell'interfaccia utente mostra dichiarazioni di debugging verdi?

Question

Modifica: Se vedi lo stesso problema (e sei abituato a NON vedere questo sotto VS2010) per favore commenta qui sotto, quindi so che non sono solo io - ma assicurati di controllare la risposta di Han per assicurarti che nessuno di questi scenari appaiono ...

---

Sto aggiornando la mia app per funzionare con .NET 4.5 in VS2012 RTM e notando qualcosa che non capisco e che è inaspettatamente verde dichiarazioni evidenziate (invece di giallo).

Ora io sono ben consapevole di che cosa si tratta supposto significare, e l'IDE è nemmeno me mostrando un po tooltip spiegazione.

Questa è la prossima istruzione da eseguire quando questa discussione ritorna dal la funzione corrente

Tuttavia non c'è assolutamente nulla asincrono o filo basati su questo codice. In questo semplice esempio sono sicuro che sarete d'accordo che string.ToUpper() non sarà disattivato in un'altra discussione. Posso passare attraverso il codice senza problemi.

Non c'è niente altro in corso e io sono sul thread principale, come si può vedere qui.

ho am utilizzando async e await e MVVM-Light (il metodo di cui sopra è il risultato di un RelayCommand), ma ho ancora ottenere questo comportamento anche quando il percorso di codice è direttamente fuori un gestore di eventi come PreviewKeyDown .

Se creo una nuova applicazione non posso duplicare questo - la colorazione è giallo come previsto - anche quando si utilizza await.

Qualcuno ha qualche idea? Sta iniziando a farmi impazzire !!

Answer 1

È verde quando il puntatore dell'istruzione corrente non è esattamente all'inizio della dichiarazione. Alcune cause comuni:

• Comune nel codice con thread, impostazione di un punto di interruzione in un thread e commutazione del contesto in un altro. L'altro thread sarà stato interrotto dal debugger in una posizione completamente casuale. Spesso nel codice che non si dispone di codice sorgente o informazioni di debug per, come String.ToUpper(), il debugger può mostrare solo il codice sorgente "più vicino"
• Utilizzando Debugger + rompere tutti per passare al debugger. Stessa idea di sopra, il puntatore dell'istruzione sarà a un indirizzo casuale
• Ottenere un'eccezione nel codice per il quale non sono presenti informazioni di debug. L'editor mostra l'ultima voce nello Stack chiamate per cui ha il codice sorgente. È necessaria la finestra dello stack delle chiamate per vedere dove è stata sollevata l'eccezione effettiva. O l'Exception Assistant, la sua ragione per essere
• Debugging codice ottimizzato.L'ottimizzatore jitter rimescola il codice piuttosto pesantemente, rendendo probabile che il debugger non può mostrare la posizione corrente con precisione
• Avere obsoleti informazioni di debug o la modifica del codice durante il debug
• debug del codice generato dal jitter x64, accade quando l'impostazione della piattaforma di destinazione del progetto è AnyCPU. Il jitter x64 ha un numero di bug cronici che non vengono risolti, generando informazioni di debug errate è uno di questi. Problemi che non sono stati risolti fino a quando non sono stati completamente riscritti, eseguiti dal progetto RyuJIT e disponibili per la prima volta in .NET 4.6. Targeting x86 nel tuo progetto EXE è la soluzione.

Answer 2

In realtà, sto affrontando anche questo problema. Questo perché mi mancava un componente di layout in modalità orizzontale, quindi controlla tutti gli ID e i componenti ed Esegui, non otterrai questo errore.