“Al momento il breakpoint non verrà colpito. Il codice sorgente è diverso dalla versione originale. " Cosa significa questo?

514

Durante il debug in Visual Studio, a volte aggiungo un punto di interruzione ma è vuoto e VS dice "Il punto di interruzione non sarà attualmente colpito. Il codice sorgente è diverso dalla versione originale." Ovviamente questo mi impedisce di essere in grado di eseguire il debug.

Cosa diavolo significa questo messaggio? Quale versione originale? Se ho appena aperto la soluzione e non ho apportato alcuna modifica al codice, come può esserci una "versione originale"?

.net visual-studio debugging

— David
fonte

36

ricompilare / compilare il progetto prima di aggiungere il punto di interruzione

— lexu

stai aprendo un progetto scritto in un'altra versione di Visual Studio?

— Mahesh Velaga,

2

È un progetto di sito Web. Non dovrebbe essere necessario crearlo esplicitamente. Dovrebbe compilare in uso. Sospetto che VS non possa costruire il sito Web, ma non me lo sta dicendo! Mahesh - no, tutta la stessa versione di VS.

— David,

Nel mio caso ... Ho diverse versioni dello stesso codice (ad esempio test.cs nella versione Live e nella versione di sviluppo .. quando ho aperto la versione di sviluppo e ho messo il punto di interruzione su test.cs ho dato lo stesso errore ma ho capito che ho messo il test di breakpoint Classe .cs che si riferiva alla versione live sln non sviluppo quindi controlla che il cs abbia già in fase di costruzione la soluzione)

— dankyy1

5

L'eliminazione delle directory bin e obj rispetto alla ricostruzione ha funzionato per me.

— Aycan Yaşıt,

277

Come dice, il "codice sorgente è diverso dalla versione originale".

Fare clic con il tasto destro sulla cartella del progetto all'interno di Esplora soluzioni e scegliere di Clean. Crea una nuova versione del progetto e il breakpoint funzionerà di nuovo!

— Veedrac
fonte

120

L'uso di clean non funziona sempre. Ho dovuto eliminare manualmente tutto nella mia cartella bin per farlo funzionare di nuovo.

— Carra,

3

Ho erroneamente fatto riferimento a una DLL nella mia cartella bin. Correzione del percorso di riferimento corretto.

— Brad Urani,

39

Per me, anche eliminare le cartelle bin e obj non ha funzionato. Ho dovuto riavviare anche Visual Studio.

— d512,

1

Trascorso quasi un giorno a trovare la soluzione. Grazie mille per aver fornito una soluzione.

— Racs,

8

Ho chiuso VS, cancellato tutte le cartelle bin e obj, ricostruito tutto, ricontrollato le configurazioni di build, la build sta funzionando. Niente da fare. Le cose semplici non dovrebbero essere così complicate. >: |

— ringhio

129

Se hai deselezionato il progetto DLL nella configurazione build di Debug , il tuo nuovo codice non verrà mai creato!

Vai a Build --> Configuration Manager ...(in VS2010) e controlla se il progetto con il codice che stai tentando di eseguire il debug è verificato per la configurazione di build corrente.

— Oliver
fonte

Grazie per il suggerimento Oliver. Questo non sta sicuramente accadendo qui, noterei abbastanza rapidamente se uno dei miei progetti non stava realizzando.

— David,

3

Ho avuto esattamente lo stesso problema, solo non ho avuto nulla di non controllato. è stato appena creato per x86 in quella finestra di dialogo, mentre il mio computer locale è x64! Quindi ho selezionato l' Any CPUopzione e funziona di nuovo.

— JP Hellemons,

3

Rimuovere i progetti dalla configurazione di debug senza un motivo valido dovrebbe essere un peccato cardinale, in quanto tale configurazione potrebbe essere utilizzata dalla macchina di creazione di elementi della configurazione (lo so che è qui), quindi alla fine potrebbe passare ciò quando dovrebbe fallire. So che potrebbe essere una delle tante fasi di costruzione ma comunque ... @Oliver Spero che il membro del team ti abbia comprato dei biscotti! :)

— Fetchez la vache,

Ho avuto questo problema quando sono passato a compilare per x86 invece di AnyCPU. Ha rimosso i progetti dalla costruzione per qualche motivo sconosciuto.

— Adam Pedley,

Il progetto è elencato per Build in Configuration Manager, quindi questo non mi ha aiutato temo :(

— Ortund

43

Per me è stato mentre lavoravo su un progetto WebSite. Dopo aver ripulito queste cartelle temporanee, ho riscontrato gli errori del compilatore corretti:

C:\Documents and Settings\%username%\AppData\Local\Temp\Temporary ASP.NET Files
C:\windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files

Alla fine ho risolto il problema quando ho scoperto che un file di classe che avevo spostato intenzionalmente in una sottocartella, in qualche modo riappariva nella cartella principale. VS lo usava mentre stavo modificando l'altro.

— AnthonyVO
fonte

2

Svuotare i file temporanei nella directory di Windows ha funzionato per me, evviva!

— ChrisFletcher,

7

Volevo solo aggiungere una risposta simile: assicurati che nessuna vecchia copia della dll del tuo progetto si trovi in una delle cartelle temporanee che ASP.NET utilizza, come C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ File temporanei ASP.NET - come indicato - ma anche file C: \ Windows \ Microsoft.NET \ Framework_64_ \ v4.0.30319 \ File temporanei ASP.NET . Uso tutto per cercare rapidamente quelle copie .

— Oliver,

12

Solo un breve suggerimento: digitando %localappdata%nella casella di ricerca si C:\Documents and Settings\%username%\AppData\Local

— arriva

1

Posso confermare che ha funzionato per me in Visual Studio 2013 su un progetto di servizio web.

— Moeri,

Ho fatto tutto questo ma non sembra aver aiutato. Ero davvero entusiasta di vedere anche questo.

— Ortund,

40

L'hai mai fatto?

Vuoi continuare ed eseguire l'ultima build di successo?

Se si seleziona la casella e si preme "Sì", verrà eseguita l'ultima build riuscita anche se il progetto non viene compilato. Ciò significa che ogni volta che imposti un breakpoint, otterrai questo errore.

Prova a cambiare questo valore:

Utensili
- Opzioni
  - Progetti e soluzioni
    - Costruisci ed esegui
      - In esecuzione, quando si verificano errori di compilazione o distribuzione: Non avviare

— Codesleuth
fonte

Non credo di averlo fatto. Grazie comunque per il link. Mi ha dato un'idea di cosa significhi quel prompt!

— David

11

Visual Studio aveva questa opzione da decenni (almeno VS98 ce l'aveva). Non ho mai capito perché qualcuno vorrebbe eseguire l'ultima build di successo. Dopotutto, se fosse quello che volevo, l'avrei lanciato direttamente, dato che non potevo comunque eseguire il debug. Non avviare sarebbe stato un valore predefinito più sensato.

— OregonGhost

6

L'ho usato alcune volte per eseguire il progetto (per qualsiasi motivo, ad esempio per mostrare a qualcun altro) mentre sono ancora nel mezzo della scrittura di codice che non verrà compilato. A volte è utile. Personalmente, lo lascio disabilitato.

— Codesleuth

3

Forse se dovessero mostrare il loro superiore quando all'improvviso arrivò. Potrebbero colpire f5 ed essere come "vedi, funziona!"

— Gigala,

33

Vai a

Utensili
- Opzioni
  - Debug
    - Generale

Deseleziona Richiedi file di origine in modo che corrispondano esattamente alla versione originale

— Rachmad
fonte

17

@Rachmad Questa soluzione funziona. Ma non sembra la soluzione completa, perché significa che i nostri file sorgente non corrispondono esattamente alla versione originale

— onmyway133

Questo è esattamente quello che stavo cercando da @entropy è giusto. Sebbene ciò consenta di impostare i punti di interruzione, il fatto è che l'origine utilizzata non corrisponde al pdb in uso. La soluzione migliore è risolverlo. In tempi impossibili, funziona alla grande.

— JamesG,

Anche con questa opzione non selezionata, l'esecuzione non raggiunge il punto di interruzione e l'errore persiste

— Ortund

12

Questa NON è una soluzione a questo problema ma una soluzione alternativa. Ovviamente non voglio lavorare con file obsoleti nel debugger.

— Obi Wan,

2

@ObiWan Non ovvio. Mi piace apportare modifiche minori e continuare il debug anche sapendo che l'origine e la build sono diverse.

— Alan Baljeu,

30

Seleziona Debug in Configurazioni soluzione , anziché Rilascio

screenshot del menu

— AdiKonstantin
fonte

1

Questo era il mio problema. Ho compilato in modalità debug, modificato il codice e successivamente eseguito in modalità di rilascio. Nessuna meraviglia che il debugger pensasse che il codice fosse diverso: i simboli di debug erano diversi. Quando ho eliminato la cartella bin come suggerito da altri, ho ricevuto un errore "nessun simbolo è stato caricato per questo documento". Fu solo allora che feci il collegamento e mi diressi verso questa risposta. Ha bisogno di più voti!

— indot_brad,

È possibile che il progetto sia disabilitato per la compilazione anche nella configurazione build di Debug. È necessario un esame della configurazione di build, il Flip-flop tra la configurazione di Debug / Release è inutile.

— Asad Saeeduddin,

Questo è stato anche per me. ha provato a pulire, ricostruendo le altre soluzioni referenziate senza risultati. Non ho notato che la soluzione mi stava fissando in faccia

— Adam Hey,

Questo è quello che è successo con me: stavo costruendo il mio progetto e sostituendo le mie DLL ancora e ancora, ma il problema non andrà via. Mi sono reso conto che il codice veniva creato in modalità Release mentre sostituivo le dll dalla cartella / bin / debug. Che stupido.

— displayName

Volevo collegarmi a un processo creato in modalità di rilascio. Il passaggio al debug ha risolto il mio problema.

— cinque

27

Prestare attenzione alla finestra "Output" in VS. Ti dirà quali assembly vengono caricati e quando. È possibile che venga caricata una versione precedente dell'assembly da qualche parte nella cartella.

Ad esempio, se si dispone di più assembly e si sta attualmente tentando di interrompere uno degli assembly di supporto, il CLR gestirà la risoluzione dell'assembly, che potrebbe caricare un altro file di assembly rispetto a quello a cui si fa riferimento nel progetto.

— Tormod
fonte

1

Vale anche la pena ricordare, ma non penso che sia il problema qui poiché sto cercando di entrare in un progetto di sito Web, non in una biblioteca di classe.

— David,

24

Chiudere Visual Studio e riaprire la soluzione può risolvere il problema, ovvero è un bug all'interno dell'IDE stesso (sto eseguendo VS2010).

Se sono in esecuzione più istanze di Visual Studio, è sufficiente chiudere l'istanza che esegue la soluzione con il problema.

— Luke Whyte
fonte

4

La chiusura di Visual Studio ha funzionato anche per me. Inoltre, con le azioni Clean / Rebuild.

— danielB

3

Ciò ha risolto la soluzione in VS 2015

— TaintedLemon

3

Problema risolto in VS 2017

— Daniel Fisher lennybacon,

Risolto il problema in VS 2012

— seebiscuit

19

Un nuovo modo per ottenere questo problema è apparso da Visual Studio 2017 15.3.1 a 15.3.5. Se si utilizza EditorConfig , l' charset=utf8opzione causa questi sintomi. Il team VS ha riprodotto questo e dice che ci stanno lavorando .

Quindi una soluzione è commentare la tua charset=utf8riga nel file .editorconfig.

Modifica: questo dovrebbe essere risolto a partire da VS 15.5.

— John Hatton
fonte

Lo stato è ora "Risolto - rilascio in sospeso" a partire da due giorni fa (9 ottobre 2017). Che è una buona notizia, poiché UTF-8 è l'unico predefinito sano per la codifica del testo in questi giorni. :-)

— rmunn,

Ho anche notato che la causa ultima di questo problema era apparentemente questo altro bugfix , in cui charset=utf8veniva interpretato come "UTF-8 con BOM". Modificando questa interpretazione su "senza BOM", alcuni file UTF-8 contenevano la BOM. Quindi, se si verifica questo problema e la correzione di Visual Studio non è stata ancora rilasciata, provare a rimuovere la DBA dall'inizio dei file di testo e questo potrebbe risolvere il problema. (Questo commento è accattonaggio per un riferimento Zero Wing ... :-))

— rmunn

Questo è stato il problema anche per me. Attualmente, questo non è stato risolto o almeno rilasciato o il bug è stato reintrodotto (versione 15.4.2)

— avidenic

12

Ciò accade spesso anche se stai usando un file riferimenti a file binari (anziché riferimenti di progetto al codice nel tuo progetto) e il file binario compilato a cui fai riferimento non è sincronizzato con il codice sorgente corrispondente sul tuo computer. Ciò può accadere perché hai scaricato una nuova versione del file binario dal controllo del codice sorgente senza il nuovo codice sorgente associato, oppure hai alcune versioni del file binario sul tuo computer e stai facendo riferimento a una vecchia copia, ecc. Se questo è effettivamente il problema, è una buona ragione per usare riferimenti di progetto tanto quanto pratici.

— Stijn
fonte

Capisco cosa intendi, e vale la pena ricordare per il futuro, ma la fonte in questione qui è un progetto di sito Web, non una biblioteca di classe.

— David,

Questo è un problema comune quando raccolgo il codice legacy che mi lascia grattarmi la testa chiedendomi quale genio abbia deciso di fare riferimento a una DLL da un progetto nella soluzione che è sempre e solo utilizzata da un altro progetto nella soluzione. sospiro

— Kell,

10

Per me, nessuno degli elementi ha risolto il problema. Ho appena aggiunto una nuova riga di codice all'interno di quella funzione, qualcosa del tipo:

int a=0;

aggiungendo questo, immagino di aver attivato Visual Studio per aggiungere questa funzione alla versione originale

— Mehrdad Babaki
fonte

7

Ciò può accadere quando l'ora del sistema cambia durante il debug o tra sessioni di debug, sia a livello di programmazione, manualmente o da un programma esterno.

— Tomi
fonte

Non riesco a +1 abbastanza. Di recente ho reinstallato Windows e non ho notato che l'orologio di sistema era spento. Abbastanza sicuro, questo cambiamento ha rovinato tutto e la ricostruzione dell'intera soluzione / progetto l'ha risolto magicamente.

— Kyle Baran,

7

C'è un'impostazione quasi impercettibile che ha risolto questo problema per me. Se esiste un particolare file di origine in cui il punto di interruzione non colpisce, potrebbe essere elencato

Esploratore di soluzioni
- tasto destro del mouse su Soluzione
  - Proprietà
    - Proprietà comuni
      - Debug dei file di origine
        
        "Non cercare questi file di origine".

Per qualche ragione a me sconosciuta, VS 2013 ha deciso di inserire lì un file sorgente e, successivamente, non ho più potuto raggiungere il punto di interruzione in quel file. Questo potrebbe essere il colpevole di "il codice sorgente è diverso dalla versione originale".

— JBSnorro
fonte

Ho affrontato lo stesso identico problema. La tua risposta mi ha aiutato! Grazie! +1

— jweyrich

5

Il problema è che le informazioni di debug non sono sincronizzate con l'assembly. La soluzione è semplice:

Vai alla tua cartella bin
Rimuovere i file .pdb
Ricostruire

Dovrebbe fare il trucco!

(la cosa strana è che una ricostruzione senza eliminare i file .pdb non funziona sempre. Riesco a vedere la data modificata essere aggiornata, ma ancora da qualche parte nella catena (debugger VS2013, IIS, cache di assembly) questa modifica non viene rilevata )

— FrankyHollywood
fonte

Build-> Clean Solution dovrebbe anche realizzare la rimozione dei file che devono essere rimossi.

— Dave,

Dopo un'enorme perdita di tempo persa a causa di questo problema, questa soluzione ha funzionato. Thx FrankyHollywood

— AD

4

È possibile visualizzare questo messaggio quando si utilizza un attivatore e l'assembly in cui è stato impostato il punto di interruzione non è stato ancora caricato.

Il punto di interruzione si risolverà quando l'attivatore carica l'assembly (supponendo che i simboli di assemblaggio e debug siano aggiornati). Un buon posto da guardare è la finestra dei moduli nel menu di debug. Lì dovresti cercare l'assembly a cui appartiene anche il tuo file. Verificare innanzitutto che il gruppo sia caricato. Quindi, da dove viene caricato? Quindi, viene caricato il file dei simboli. Ancora una volta, da dove viene caricato il file dei simboli? Infine controlla le versioni di entrambi.

— Stijn
fonte

4

Ho incontrato anche questo. Le condizioni che hanno causato il mio problema:

Sto eseguendo un'istanza IIS7 completa localmente
Sto eseguendo il versioning del mio software in progetti separati

L'avevo causato aprendo una versione precedente (VS ha chiesto di chiedere se volevo puntare a questa istanza nel debug di IIS, ho risposto "Sì"), quindi aprendo la versione corrente (rispondendo nuovamente al prompt di IIS con un "Sì" ), quindi tentando di eseguire il debug nella versione precedente.

Per risolvere, ho semplicemente chiuso e riaperto la versione precedente e prevista, affermandola ancora una volta come fonte di debug.

— baker.nole
fonte

3

Prova a disabilitare e reimpostare il breakpoint mentre esegui in modalità debug invece di farlo prima di avviare la modalità debug.

— mikeTheLiar
fonte

3

Ciò accade anche durante il debug di un progetto C ++ che carica un modulo che è stato implementato con un linguaggio CRL (Managed C ++, C # ecc.). In questa situazione il messaggio di errore è davvero fuorviante.

La soluzione consiste nel mettere la proprietà di configurazione del supporto Common Language Runtime (CLR) nel progetto di avvio e ricompilarlo.

— Stijn
fonte

3

Se hai più di un progetto nella tua soluzione , assicurati che il progetto corretto sia impostato come StartUp Project. Per impostare un progetto particolare come Progetto di avvio della soluzione, fare clic con il pulsante destro del mouse sul progetto, scegliere Set As StartUp Project.

Dopo aver impostato correttamente il mio progetto StartUp, il thread ha raggiunto il punto di interruzione desiderato.

— nome da visualizzare
fonte

Vale anche la pena notare che se il tuo punto di interruzione si trova in un progetto che NON è il tuo progetto di avvio, e NON PUO 'essere fatto il tuo progetto di avvio (perché ad esempio devi avere un progetto diverso da quello di avvio) puoi (dopo aver avviato quello principale) fare clic con il tasto destro del mouse e selezionare Debug >> Avvia nuova istanza del progetto che presenta il punto di interruzione in cui si desidera colpire

— Caius Jard

3

L'ho sperimentato in una build a 32 bit su vs2017.

Esattamente nessuna delle soluzioni ha funzionato per me. Ho riavviato, ho cancellato i file IDE, pulito la soluzione integrata, estratto da Git Repo e ricostruito la soluzione senza risultati.

Stavo estraendo una dipendenza a 64 bit da Nuget e non appena ho usato l'assembly, i sorgenti non venivano più inseriti nell'eseguibile finale e invece venivano creati i sorgenti memorizzati nella cache IDE.

Ho rimosso la configurazione di nuget, rimosso l'assembly di riferimento, scaricato l'origine, creato log4net manualmente, firmato, aggiunto in una cartella nel mio progetto, aggiunto riferimento ad esso e sono stato in grado di eseguire nuovamente il debug.

Questo è stato un dolore, spero che si alzi nell'elenco delle risposte che tutti possano vedere.

Modifica: durante la compilazione non si sono verificati errori nonostante l'opzione "prompt on error build" fosse attivata nelle impostazioni IDE.

— 2 giri
fonte

3

Per me la soluzione era nascosta nelle Advanced Build Settingsproprietà del progetto:

Per una ragione sconosciuta era impostato su none: impostandolo su faceva fullcolpire i punti di interruzione.

Per accedere a questa finestra di dialogo, apri le proprietà del progetto, quindi vai a Build, quindi seleziona il Advanced...pulsante nella parte inferiore della pagina.

— riqitang
fonte

3

Ho avuto lo stesso problema in diversi progetti in un progetto di architettura a più livelli e il problema riguardava le configurazioni: la casella di controllo build per il progetto selezionato non è stata selezionata. quindi il problema è stato risolto per un progetto.

Per un altro livello stava dando lo stesso problema anche se la configurazione è abilitata nelle configurazioni. Ho fatto tutte le altre opzioni come riavviare la pulizia del progetto, ma nessuna di esse mi ha aiutato. Alla fine ho deselezionato la casella di controllo build per quel particolare progetto e pulito e ricostruito. nuovamente contrassegnato la casella di controllo e ha fatto lo stesso. quindi il problema è stato risolto.

Spero che sia di aiuto..

— Priyankara
fonte

2

Nel mio caso, mi stavo collegando a un processo in esecuzione in VS 2012. Durante il collegamento, ti viene data la possibilità di eseguire il debug in varie modalità (nativo, script, silverlight, gestito 2.0, gestito 4.0, ecc.). Per impostazione predefinita, il debugger seleziona automaticamente la modalità. Tuttavia, Automatic non fa sempre la scelta corretta. Se il processo contiene più tipi di codice, assicurarsi che il debugger stia utilizzando quello corretto.

— tono silenzioso
fonte

Nel mio caso mi stavo collegando a w3wp.exe per eseguire il debug del codice .NET, ma per qualche motivo stava collegando il debugger di script che non era in grado di vedere i miei punti di interruzione C #. Modificandolo nel debugger .NET ha permesso il funzionamento dei miei punti di interruzione C #.

— Oran Dennison,

2

Nel mio caso, stavo sviluppando un'app di Windows CE, testata contro un emulatore. Il problema era che l'eseguibile non era distribuito nell'emulatore, quindi il .pdb (nell'ambiente di sviluppo) non era sincronizzato con .exe (nell'emulatore), perché il nuovo .exe non è mai stato copiato nell'emulatore. Ho dovuto eliminare il file .exe nell'emulatore per forzare una nuova distribuzione. Quindi ha funzionato.

— Julen
fonte

2

Quello che ha funzionato per me è stato cambiare la piattaforma della soluzione da x86 a Any CPU. Dopo essere passato a Qualsiasi, ho impostato un indirizzo di arresto, ho eseguito il sito Web, aperto la pagina, fatto clic sul pulsante e si è arrestato. Ho chiuso il sito, sono tornato su x86 ed ho eseguito la stessa sequenza con successo.

— John
fonte

2

Forse la scelta della CPU non influisce affatto sul problema ed è solo il fatto che forza una ricostruzione?

— jwg

Userà un'altra cartella bin, probabilmente c'era una vecchia dll nella tua qualsiasi mappa della CPU.

— Carra,

Ho avuto questo problema mentre la piattaforma attiva x86 (che non ho mai usato), passando a Win32 ha risolto il problema. Il PC è condiviso, quindi qualcun altro ha impostato quella piattaforma per qualsiasi motivo.

— Zac,

2

In Windows 7, Visual Studio Express 2010, se è stata attivata l'opzione Utilizza la modalità di compatibilità per Windows XP SP3 , potrebbe verificarsi questo errore.

Deselezionai l'opzione e funzionò di nuovo perfettamente. Fare clic con il tasto destro sul collegamento a VS o all'eseguibile, selezionare proprietà e quindi compatibilità .

— Pete
fonte

1

Ciò che potrebbe accadere qui è che la configurazione della tua versione cambia da x32 a x64 quando disabiliti la modalità di compatibilità e potresti non avere tutti i tuoi progetti selezionati per la compilazione in x32. Perché alcuni progetti sono disabilitati per build in x32 è qualcosa di cui dovrai parlare con i membri del tuo team.

— Asad Saeeduddin,

Quello era esattamente il mio problema. Grazie!

— Johan Holtby,

2

Prima ho provato dalla riga di comando;

l'eliminazione dei file temporanei dalla riga di comando ha funzionato.

C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ File ASP.NET temporanei> root rd / s

Quando disabilito l' opzione "Abilita solo il mio codice" in Strumenti -> Opzioni -> Debug -> Generale

Il problema si è risolto per me. È un'applicazione WCF, stava cercando di eseguire il debug di una pagina ashx. http://blogs.msdn.com/b/zainnab/archive/2010/10/25/understanding-just-my-code.aspx

— Teoman Shipahi
fonte

2

Mi è successo perché avevo altri progetti nella soluzione che non stavano costruendo. Dopo aver scaricato quei progetti problematici (facendo clic con il pulsante destro del mouse sul progetto in Esplora soluzioni -> Scarica progetto), ho ricostruito la soluzione ed eseguito di nuovo - il punto di interruzione è stato raggiunto!

— Sarah
fonte

2

È successo su Visual Studio 2017 dopo aver aggiunto i file esistenti al progetto. Questo ha funzionato per me:

chiudi la soluzione,
vai a SolutionFolder\.vs\SolutionName\v15\sqlite3e rimuovistorage.ide
apri di nuovo la soluzione

— Laurian
fonte

Grazie per questa soluzione! Nessuno prima ha funzionato, e questo mi ha salvato la giornata :)

— StefanaB,

2

Assicurarsi di non essere in modalità di rilascio quando si tenta di eseguire il debug.

— Entra
fonte