Errore: impossibile accedere al file bin / Debug / ... perché è utilizzato da un altro processo

Quando eseguo il debug del mio progetto, ottengo il seguente errore:

"Impossibile copiare il file" obj \ Debug \ My Dream.exe "in" bin \ Debug \ My Dream.exe ". Il processo non può accedere al file" bin \ Debug \ My Dream.exe "perché è utilizzato da un altro processi."

Utilizzando Process Explorer, vedo che MyApplication.exe era fuori ma il processo di sistema lo utilizza ancora anche se ho interrotto il debug in precedenza. Ogni volta che cambio il mio codice e inizio il debug, succederà. Se copio il progetto su USB ed eseguo il debug, funziona correttamente.

Perché? Come posso correggere questo errore?

Uso Window 7 Professional. Con Xp non ho mai ricevuto questo errore.

Ugh, questo è un vecchio problema, qualcosa che ancora si apre in Visual Studio una volta ogni tanto. Mi ha morso un paio di volte e ho perso ore a ricominciare e combattere con VS. Sono sicuro che sia stato discusso qui su SO più di una volta. Se ne è parlato anche nei forum MSDN. Non esiste una soluzione effettiva, ma ci sono un paio di soluzioni alternative. Inizia la ricerca qui .

Quello che sta succedendo è che VS acquisisce un blocco su un file e quindi non lo rilascia. Ironia della sorte, quel blocco impedisce a VS stesso di eliminare il file in modo che possa ricrearlo quando si ricostruisce l'applicazione. L'unica soluzione apparente è chiudere e riavviare VS in modo che rilasci il blocco sul file.

La mia soluzione originale era aprire la cartella bin / Debug e rinominare l'eseguibile. Non puoi eliminarlo se è bloccato, ma puoi rinominarlo. Quindi puoi semplicemente aggiungere un numero alla fine o qualcosa del genere, che ti consente di continuare a lavorare senza dover chiudere tutte le finestre e attendere il riavvio di VS. Alcune persone l'hanno persino automatizzato utilizzando un evento di pre-compilazione per aggiungere una stringa casuale alla fine del vecchio nome del file di output. Sì, questo è un trucco gigantesco , ma questo problema diventa così frustrante e debilitante che farai qualsiasi cosa.

In seguito ho appreso, dopo un po 'più di sperimentazione, che il problema sembra sorgere solo quando si crea il progetto con uno dei designer aperto. Quindi, la soluzione che ha funzionato per me a lungo termine e mi ha impedito di affrontare di nuovo uno di quegli stupidi errori è assicurarmi di chiudere sempre tutte le finestre di progettazione prima di costruire un progetto WinForms. Sì, anche questo è un po 'scomodo, ma sicuramente batte il fatto di dover riavviare VS due volte all'ora o più.

Presumo che questo si applichi anche a WPF, anche se non lo uso e non ho riscontrato personalmente il problema lì.

Inoltre non ho ancora provato a riprodurlo su VS 2012 RC. Non so se è stato ancora risolto o meno. Ma la mia esperienza finora è stata che riesce ancora a comparire anche dopo che Microsoft ha affermato di averlo risolto. È ancora presente in VS 2010 SP1. Non sto dicendo che i loro programmatori siano idioti che non sanno cosa stanno facendo, ovviamente. Immagino che ci siano solo più cause del bug e / o che sia molto difficile riprodurlo in modo affidabile in un laboratorio. Questo è lo stesso motivo per cui non ho personalmente segnalato alcun bug su di esso (anche se ho fatto +1 su altre persone), perché non riesco a riprodurlo in modo affidabile, piuttosto come l'Abominevole uomo delle nevi.

_{<end rant che non è rivolto a nessuno in particolare>}

Ho riscontrato questo errore in precedenza, anche in Visual Studio 2008. È tornato e più diffuso in Visual Studio 2012.

Ecco cosa faccio.

Incolla questo nell'evento di pre-compilazione del progetto problematico:

if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"

Computer (tasto destro) -> gestisci -> Servizio e applicazione -> servizio -> Abilita esperienza applicazione

Ha funzionato per me!

Ho riscontrato lo stesso problema in Visual Studio 2013. Non sono sicuro di cosa abbia causato questo problema per il mio progetto, ma sono riuscito a risolverlo pulendo la soluzione e ricostruendola.

1. Crea> Soluzione pulita
2. Compila> Ricostruisci soluzione

Almeno nel mio caso ho notato che Visual Studio 2012 stava creando almeno due processi fantasma msbuild.exe, che non sono morti dopo la compilazione. Questi zombi apparentemente stanno causando la comparsa di blocchi di file.

L'uccisione di msbuild.exe è una soluzione una tantum, deve essere eseguita in base alla build.

Ma poi ho capito che potevo disabilitare la compilazione parallela una volta per tutte - sono andato in Strumenti> Opzioni> Progetti e soluzioni> Compila ed esegui> "numero massimo di build di progetti paralleli" - per impostazione predefinita ha valore 8, io sono passato a 1. Funziona a meraviglia.

Ovviamente le build sono un po 'più lente ora, ma è meglio prevenire che curare. Almeno per questo particolare piccolo progetto non avevo bisogno di più di un thread di build.

Capisco che questa sia una vecchia domanda. Sfortunatamente stavo affrontando lo stesso problema con la mia .net core 2.0applicazione in visual studio 2017. Quindi, ho pensato di condividere la soluzione che ha funzionato per me. Prima di questa soluzione avevo provato i passaggi seguenti.

1. Studio visivo riavviato
2. Chiuse tutte le applicazioni
3. Pulisci la mia soluzione e ricostruisci

Nessuno dei passaggi precedenti non ha risolto il problema.

Quindi ho aperto il processo mio Task Managere selezionato e quindi ho dotnetfatto clic sul pulsante Termina attività. Successivamente ho aperto il mio Visual Studio e tutto funzionava bene.

Vedi la mia risposta qui se hai questo problema durante l'esecuzione di unit test. Risposta copiata di seguito:

Basandomi sulla risposta di Sébastien, ho aggiunto un passaggio di pre-compilazione al mio progetto di test per terminare automaticamente tutti gli vstest.*eseguibili ancora in esecuzione. Il seguente comando di pre-compilazione ha funzionato per me:

taskkill /f /im vstest.*
exit 0

Il exit 0comando è alla fine per evitare errori di compilazione quando non ci sono vstest.*eseguibili in esecuzione.

Recentemente ho avuto problemi con Visual Studio 2012 con la stessa descrizione dell'errore: "Il processo non può accedere al file perché è utilizzato da un altro processo ..."

Per risolvere questo problema prima di tutto è necessario comprendere l'applicazione che ancora lo utilizza. Ho chiuso tutti i processi come "MSBuild" e "MSBuild host". Ma questo non basta. Se hai installato "Code Contracts" e attivato, a volte occorrono le tue DLL per controllare e interrompere questa operazione.

Quindi, è necessario interrompere tutti i processi di "CCCheck.exe" e questo è tutto.

Infine, per capire che il processo sta utilizzando la tua DLL, puoi sempre provare a eliminare la cartella "obj" nel tuo File Manager e questa operazione fallirà, potresti vedere la "Finestra dei messaggi" con la descrizione dell'operazione in sospeso. Inoltre, come variante, puoi provare a utilizzare l'applicazione "Sys Internals Suite".

Ha funzionato per me. Task Manager -> Nome del progetto -> Termina attività. (avevo 3 stessi processi con il nome del mio progetto);

VS 2013; Win 8;

Assicurati che qualsiasi esecuzione precedente dell'applicazione (ad esempio, avvio senza opzione di debug) sia effettivamente interrotta. Stavo lavorando su un'applicazione WPF, avviata senza eseguire il debug e l'avevo ridotta a icona quando continuavo a ricevere l'errore. Dopo aver chiuso l'applicazione, il comportamento di VS è tornato alla normalità.

Sono stato afflitto da questo problema in Visual Studio 2017. È iniziato circa due o tre settimane fa e ha seriamente compromesso la mia produttività. Clean e Rebulid non hanno funzionato; anche riavviare la mia macchina non fa il lavoro.

Un modo per affrontare il problema è pulire l'assieme incriminato e creare (anziché ricostruire) il progetto che si desidera eseguire immediatamente dopo. Funziona circa il 30% delle volte.

Tuttavia, probabilmente la soluzione più affidabile che ho trovato è aprire un prompt dei comandi per gli sviluppatori e utilizzare msbuilddirettamente. L'ho fatto negli ultimi tre giorni e finora il problema non si è verificato una sola volta.

Nel mio caso è stato abilitato "Mostra tutti i file". Visual Studio 2017

Corri taskmanager.
Individualo netcoreed eliminalo.
È quindi possibile eliminare il file manualmente o eseguendo Clean.

Questa è pura speculazione e non una risposta.

Tuttavia, ho avuto questo problema per un po '.

Sono arrivato dopo un po 'di tempo per sospettare un'interazione tra VS e le mie precauzioni AV.

Dopo un po 'di gioco, sembra che possa essere andato via quando ho modificato il mio antivirus in modo che tutto sotto il file

C: \ Users [nome utente] \ AppData \ Local \ Microsoft \ VisualStudio \ 10.0 \ ProjectAssemblies

cartella non è stata inclusa nella protezione in tempo reale.

Sembra che la build scriva effettivamente prima la DLL qui, quindi la copia nella posizione di build finale.

Potrebbe essere troppo tardi. Ma ho riscontrato un problema simile e nel mio caso il progetto aveva un'auto referenza. Quindi, eliminarlo dai riferimenti ha funzionato a meraviglia !!!

Ho trovato il modo più veloce senza chiudere i moduli o riavviare VisualStudio è andare alla pagina di compilazione del progetto e fare clic sul pulsante "Opzioni di compilazione avanzate ...". Quindi apportare qualsiasi modifica a una delle opzioni (ad esempio, cambiare Genera informazioni di debug da Completo a solo pdb), quindi fare clic su OK. Funziona ogni volta e dovrà farlo fino a quando MS non risolverà questo bug (non ho mai avuto questo problema fino a quando non sono passato da VS2012 a VS2013)

Un'altra nota, se non puoi pulire il progetto o la soluzione, non verrà creato. I file sono decisamente bloccati da VS (non è un problema antivirus, almeno non nel mio caso)

Ho provato tutti questi suggerimenti e altri suggerimenti trovati altrove e l'unica cosa che ha funzionato per me è stato il riavvio del computer. Poi ho fatto una soluzione pulita seguita dalla ricostruzione. Sto usando Visual Studio 2013 come riferimento.

Ho riscontrato lo stesso problema e quello che ho scoperto è che in realtà sono in esecuzione più applicazioni Windows Form in background. Succede quando la tua domanda ha due moduli e chiudi il secondo modulo che non è il tuo modulo principale, quindi l'applicazione non verrà completamente chiusa.

Di solito eseguo la mia applicazione

• tramite il suo exe o
• eseguito senza eseguire il debug

La soluzione è chiudere l'altra istanza dell'applicazione Windows Form . Questo è un modo per chiudere sempre l'istanza dell'applicazione.

Comando pre build

(if exist "$(TargetDir)*old.pdb" del "$(TargetDir)*old.pdb") & (if exist "$(TargetDir)*.pdb" ren "$(TargetDir)*.pdb" *.old.pdb)

Aiutato

[Risolto] Errore: impossibile accedere al file bin / Debug / ... perché è utilizzato da un altro processo:

Mi sto avvicinando al fatto che ottieni questo errore mentre stavi cercando di eseguire due finestre una dopo l'altra, ad esempio caricando prima un modulo, poi a volte scompare automaticamente e il secondo modulo viene caricato sullo schermo.

Fondamentalmente, è necessario chiudere il primo modulo in esecuzione in background e il motivo principale alla base di questo errore.

Per chiudere il primo modulo è necessario aggiungere queste due righe di codice nel secondo gestore di eventi di caricamento del modulo.

    Form1 form = new Form1();
    form.Close();

Questo risolverà perfettamente l'errore.

Una semplice soluzione è andare alla cartella bin \ Debug, eliminare tutti i file in quella cartella, quindi ricostruire. Se non funziona, chiudi Visual Studio, quindi vai alla cartella bin \ Debug utilizzando Esplora file, a sinistra fai clic su File> Apri prompt dei comandi> Apri prompt dei comandi come amministratore> Inserisci questo comando "DEL / F / Q / A * "> quindi ricostruire

Ho trovato la risposta di Cody Gray parzialmente utile, in quanto mi ha indirizzato alla vera fonte del mio problema che alcuni di voi potrebbero anche riscontrare: l'esecuzione del test di Visual Studio rimane aperta per impostazione predefinita e mantiene un blocco sui file.

Per interrompere questo comportamento prevalentemente inutile, segui le istruzioni da https://connect.microsoft.com/VisualStudio/feedback/details/771994/vstest-executionengine-x86-exe-32-bit-not-closing-vs2012-11-0 -50.727-1-rtmrel

Deseleziona il menu Test -> Impostazioni di test -> "Mantieni il motore di esecuzione del test in esecuzione"

Il mio problema era che dotnet si bloccava e ogni volta che VS provava a creare una nuova dll o ad accedere a una vecchia, il processo dotnet si agganciava alla dll e impediva a Visual Studio di clonare la dll. La soluzione è solo terminare tutte le attività dotnet nel task manager (rimuoverà effettivamente solo quella morta, se stai cercando di terminarne una e non si spegnerà, significa che funziona).

Chiudi VisualStudio, ctrl-alt-canc, seleziona Task Manager, trova e termina tutti i processi MSBuild - VisualStudio ha fondamentalmente un bug piuttosto grave in cui perde il controllo del suo debugger e il debugger mantiene un blocco sul file .pdb nel debug / bin cartella. Dopo aver terminato tutti i processi MSBuild (debugger), eliminare la cartella / debug / bin e riaprire la soluzione in Visual Studio. Adesso sei a posto. Microsoft ha bisogno di aggiustare questa merda.

Ho aperto una domanda separata relativa a VS 2017 che aveva un comportamento simile dopo un aggiornamento. Tuttavia, il problema sembrava essere stato generato dal programma antivirus.

Ho aggiunto la cartella bin all'elenco di esclusione antivirus, riavviato la macchina e ora sembra funzionare.

Ho risolto questo problema ..

vicino al debug vedi un menu a tendina con alcune configurazioni. L'impostazione predefinita era Qualsiasi CPU. Seleziona x86 ed esegui il programma che funzionerà. Se x86 non è presente, vai al gestore di configurazione e aggiungi il file x86

Un altro kludge, ugh, ma è facile e funziona per me in VS 2013. Fare clic sul progetto. Nel pannello delle proprietà dovrebbe esserci una voce denominata File di progetto con un valore

(il nome del tuo progetto) .vbproj

Modifica il nome del progetto, ad esempio aggiungendo -01 alla fine. Il file .zip originale che era bloccato è ancora lì, ma non è più referenziato ... quindi il tuo lavoro può continuare. La prossima volta che il computer viene riavviato, il blocco scompare ed è possibile eliminare il file errato.