VS 2015 Update 1 - Affermando che sto eseguendo il debug di una build di rilascio

Dopo l'aggiornamento a VS 2015 aggiornamento 1, se eseguo un progetto Web (MVC), interrompi l'applicazione, quindi prova a eseguirla di nuovo, VS si interrompe e viene visualizzata una finestra di dialogo che richiede

Stai eseguendo il debug di una build di rilascio di <myproject.dll>.

L'utilizzo di Just My Code con build di rilascio che utilizzano le ottimizzazioni del compilatore si traduce in un'esperienza di debug degradata (ad esempio, i punti di interruzione non verranno raggiunti).

Il problema è che non sto eseguendo una build di rilascio. Sto chiaramente eseguendo la (stessa) build di debug che ho appena eseguito! Perché VS pensa che stia eseguendo una build di rilascio?

La pulizia della soluzione e la riesecuzione cancella il messaggio di errore, quindi qualcosa viene nascosto da qualche parte.

La parola da parte di Microsoft è che si tratta di un problema noto (originariamente era indirizzato al team del debugger, ma è stato determinato che si trattava di un problema di build ed è ora nelle mani del team del sistema di progetto. Ci sono altri bug aperti su questo problema ed è classificato come Priorità 1, quindi dovrebbe essere sulla buona strada per il prossimo aggiornamento. Anche se, come ci si aspetterebbe, non si possono fare promesse su quando verrà rilasciato (o cosa è effettivamente contenuto nell'aggiornamento).

Così. È noto e ci si sta lavorando. Almeno disattivare "Abilita solo il mio codice" nelle Opzioni generali di debug sembra essere una soluzione per ora.

Come accennato da @romanoza, Microsoft ha aggiornato il bug report (ora mancante) di Microsoft Connect, (precedentemente situato qui , nel caso in cui tu sia in grado di trovare un archivio da qualche parte) con le seguenti informazioni:

Deseleziona l'impostazione Debug -> Opzioni -> Sopprimi ottimizzazione JIT al caricamento del modulo (solo gestito)

Questa è la soluzione. Continuano a dire più tardi:

Consigliamo alle persone di lasciarlo deselezionato poiché averlo deselezionato migliorerà sia le prestazioni che il comportamento del solo codice in scenari specifici.

Infine, il riconoscimento:

È un bug che non funziona con quell'impostazione abilitata e stiamo lavorando a una correzione per quella situazione nel caso in cui alcuni clienti vogliano ancora eseguire il debug con quell'impostazione attivata.

Aggiornamento : Sulla base dei commenti, sembra che la scatola è ora un selezionata per impostazione predefinita per alcuni sviluppatori, e che il controllo possa risolvere lo stesso identico problema in alcuni casi. Molto strano.

Ho notato che le risposte qui sono incomplete, stavo avendo lo stesso problema ed è stato risolto aprendo le proprietà del progetto e sotto la scheda build e debug configurazione deselezionando "ottimizza codice" . Dovresti anche controllare il gestore di configurazione come menzionato sopra per assicurarti che sia anche corretto. La risposta è arrivata da questo post e dovrebbero ottenere il merito: VS2015 Project non viene più eseguito in modalità debug

Grazie,

Ho risolto il problema impostando la configurazione su Debug nella finestra Configuration Manager come suggerito in questa risposta .

La pulizia (e la ricostruzione) della soluzione funziona per me come soluzione temporanea. Inoltre puoi selezionare Debug> Opzioni e deselezionare la Suppress JIT optimizationcasella di controllo.

Ho riscontrato lo stesso problema dall'aggiornamento a VS2015 Update 1.

Ho trovato un rapporto simile sui forum di Visual Studio di Microsoft che punta a un rapporto di bug che è stato generato con loro qui

Esistono varie soluzioni alternative, ma penso che il problema di fondo sia che IIS Express non si chiude al termine del debug e non è dovuto al fatto che l'opzione Modifica e continua non è selezionata. Soluzione più rapida che riesco a trovare fino a quando il bug non viene risolto:

• Fare clic con il tasto destro sull'icona IIS Express nella barra delle applicazioni e uscire dopo il debug (credito a David Totzke che ha fornito una soluzione alternativa alla segnalazione di bug)

Non eccezionale, ma al momento non credo che sia disponibile una soluzione adeguata.

Ho riscontrato lo stesso problema. Ho risolto il problema eliminando manualmente tutti i file dalla cartella "bin" e quindi ricostruendo la soluzione. Non ricevo più questa finestra di dialogo.

Nel mio caso, avevo cambiato la "Piattaforma della soluzione attiva" per l'intera soluzione in "Configuration Manager" da x86 a Qualsiasi CPU, risolto il problema

Controlla le proprietà di configurazione della tua soluzione. Mi sono imbattuto nello stesso problema e ho scoperto che la mia configurazione di debug stava effettivamente costruendo alcuni progetti con una configurazione di rilascio.

Ho notato che Visual Studio non stava uccidendo il processo iisexpress dopo aver interrotto il debugger. L'uccisione manuale del processo sembrava risolverlo per me.

Sembra che ora sia stato risolto nell'aggiornamento 2.

Sembra che ci siano tante soluzioni quante sono le persone che hanno il problema, ma nel mio caso ho dovuto rimuovere e aggiungere nuovamente un riferimento al progetto. Il riferimento al progetto era in un progetto di unit test nella stessa soluzione.

Nel mio caso, il messaggio di errore era corretto. Stavo eseguendo un'applicazione che caricava la versione rilasciata. Quindi l'ho corretto facendo caricare all'applicazione la versione di debug.

Elementare, lo so, e mi rendo conto di farmi sembrare un idiota. Ma a volte il problema è esattamente ciò che viene segnalato.

Verifica che l'URL del progetto IIS punti effettivamente dove pensi che faccia. In caso di dubbio, fare clic sul pulsante "Crea directory virtuale".

Recentemente ho avuto questo problema in cui stavo eseguendo una versione temporanea di una base di codice di produzione e avevo ripunto la cartella in IIS alla versione temporanea, che era, in effetti, in esecuzione una build di produzione, non la versione di debug che stavo cercando di eseguire il debug.

Per me, ho trovato 3 rif. Cartella \ Release \ in questo file FileListAbsolute.txt:

C: \ Projects \ MyWebApp.Web \ obj \ Release \ MyChildWebApp.Web.csproj.FileListAbsolute.txt

Erano così:

C: \ Projects \ MyWebApp.Web \ obj \ Release \ MyChildWebApp.Web.csprojResolveAssemblyReference.cache

C: \ Projects \ MyWebApp.Web \ obj \ Release \ MyChildWebApp.Web.dll

C: \ Projects \ MyWebApp.Web \ obj \ Release \ MyChildWebApp.Web.pdb

E semplicemente rimuovendo quelle 3 linee fuori da VS e poi riaprendo la soluzione il problema è stato risolto. Spero che aiuti.

Ho provato tutte le risposte e quella che ha funzionato per me è stata rimuovere alcuni pacchetti NuGet, non solo il riferimento, ma rimuovere il pacchetto, nel mio caso PostSharp. All'inizio ho provato a rimuovere il riferimento da tutti i progetti, e non funziona, poi ho semplicemente rimosso i pacchetti dal manager. Non so quale sia esattamente la ragione, ma è quello che ha risolto i miei problemi, spero che possa aiutare qualcuno là fuori.

Riavvia Visual Studio. Questo ha risolto il problema per me nel 2017 Professional.

Ecco cosa ha funzionato per me.

Se un progetto web, vai alle proprietà del progetto del progetto web e

1. Se è selezionato IIS locale, riavviare il server IIS.
2. Se è selezionato IIS Express, esci da IIS express dall'icona sulla barra delle applicazioni.

Sembra che alcune dll vengano memorizzate nella cache, quindi i passaggi precedenti invalideranno la cache.

Ciò è accaduto in Visual Studio 2019 su un'app UWP. Deselezionando Optimize Code nelle impostazioni csproj / build è stato risolto.

Abbastanza sicuro che questo sia stato risolto in Visual Studio 2015 Update 2.

Lo vedevo sempre (più volte al giorno) e non l'ho visto una volta dall'aggiornamento all'aggiornamento 2.