2009-11-30 15 views
25

Utilizzo di Visual Studio 2010 beta, quando eseguo la mia applicazione all'interno dell'IDE per il debug, funziona perfettamente la prima volta. Tuttavia, dopo aver chiuso la sessione di debug, sia per chiudere l'applicazione o facendo clic sul pulsante di arresto di debug, tutti i tentativi successivi di eseguire il debug dell'applicazione non riuscire con:Perché ottengo errori "file utilizzato da un altro processo" quando eseguo il debug in Visual Studio?

di errore 1 Impossibile copiare il file "obj \ Debug \ Application.dll " a " bin \ Debug \ Application.dll ". Il processo non può accedere al file "bin \ Debug \ Application.dll" perché è in uso da un altro processo .

Handle.exe di SysInternals mostra gli handle aperti, ma anche se chiudo le maniglie, l'errore non scompare. Qualsiasi tentativo di eliminare il file provoca manualmente un messaggio di errore "Accesso negato".

Per risolvere questo problema, devo riavviare completamente Visual Studio, dopo il quale la sessione di debug funzionerà una volta e si fermerà di nuovo.

Non sono del tutto sicuro quando è iniziato, ma sono abbastanza sicuro che sia abbastanza recente.

UPDATE: Dopo forzo chiudere le maniglie Application.dll, ottengo il seguente errore da VS:

di errore 1 Impossibile aprire il file copiare "obj \ Debug \ Application.dll" a "bin \ Debug \ Application.dll". L'operazione richiesta non può essere eseguita su un file con una sezione mappata dall'utente aperta.

Che diamine è una "sezione mappata dall'utente" ??

UPDATE 2: Sembra che questo problema si verifica quando ho un modulo aperto in visualizzazione Struttura durante il tentativo di eseguire il debug. Ho intenzione di fare un po 'di risoluzione dei problemi e quindi pubblicare i miei risultati.

UPDATE 3: Penso di averlo ridotto a un modulo utilizzando un UserControl.

+1

Hai provato uccidendo il processo Applocation.vshost.exe piuttosto che il riavvio di Visual Studio? – Nestor

+0

Sì, NON PUO 'essere ucciso. Il processo non morirà finché non chiudo VS. –

+1

"Sembra che questo problema si verifichi quando ho un modulo aperto in visualizzazione Struttura" Lo ha fatto per me. Stavo ricevendo il tuo errore. Quando ho chiuso tutti i file XAML aperti, l'errore è andato via. – user2023861

risposta

11

Per essere onesti con voi, sembra un bug in VS2010. Per qualche motivo non chiude gli handle aperti quando il debugger si arresta. L'eliminazione del processo VS chiude automaticamente tali handle, consentendo di accedere nuovamente al file. Come soluzione, potresti dare un'occhiata a unlocker che è gratuito e funziona eccezionalmente bene. So che non è una buona risposta, ma dovrebbe essere più veloce di riavviare VS. Potresti anche prendere in considerazione l'invio di una segnalazione di bug ...

Modifica: Unlocker non funziona su sistema operativo a 64 bit, tuttavia lo è LockHunter.

+29

Aspetta, Chris Thompson risponde a Chris Thompson? LOL. –

+1

@Andy Lo so, ho fatto un doppio take ;-) –

+1

È un bug confermato in VS2010 che dovrebbe essere risolto in SP1. –

2

Ho visto il servizio di indicizzazione di Windows causare questo. Disabilitarlo aiutato Anche gli scanner antivirus possono essere colpevoli. Anche le chiamate Mutliple Application.Close() possono causare questo.

EDIT: Certo, dal momento che funziona sempre la prima volta, suppongo che siano improbabili.

8

Ecco come ho risolto questo problema

* apro le proprietà del progetto, * selezionare la scheda di compilazione, * Cancella il percorso di uscita, * e buid (questo creerà la dll nella cartella principale) * tornare al percorso di uscita e selezionare sfoglia (passare alla directory bin per eseguire il debug/release) e voilà!

+2

Voilà! Ha funzionato anche per me, grazie! – Dan

+0

Wow! tu sei l'uomo! – Maciej

+0

Questo è riemerso per me in VS2015 e questo ha risolto il mio problema. – GibralterTop

0

Ho riscontrato lo stesso problema e nel mio caso ho avuto il file in questione aperto in Visual Studio. La chiusura di tutti i file ha aiutato.

1

Aveva lo stesso problema. Le seguenti cose aiutato

  1. chiusura tutti i file di progettazione durante il debug
  2. utilizzando Unlocker

Anche la mia applicazione apre una porta. Durante il debug di un'eccezione è stato lanciato e il programma si chiude. Finendo il programma ho chiuso la porta. Anche questo ha aiutato.

Ma sicuramente, bug con VS2010.

-1

Questo è così frustrante. Pensare davvero di passare a VS2013 e VS2010 è carico di problemi e la MS sembra non curarsene. Alcuni di noi non hanno il lusso di pagare per il nuovo software, ma sembra che dovrò mordere il proiettile. Ho avuto questo problema costantemente per oltre due settimane. Ho eliminato qualsiasi impostazione per VS2010 Potrei aver usato Devenv/Resetsettings, lanciato VS2010 come admin, e ancora ottenere questo problema. Quando MS dice che non possono riprodurre questo in laboratorio perché hanno un sistema incontaminato o stanno solo mettendo su schermi di fumo. Sto letteralmente tirando fuori i miei capelli con questo.

+0

Sento il tuo dolore! –

0

Ho affrontato lo stesso errore e sono rimasto bloccato per molti giorni. Finalmente risolto il problema. Stavo lavorando su un progetto che aveva molte librerie di classi aggiunte in esso. Ho aggiunto il riferimento di queste librerie per il mio progetto principale ed erroneamente

added reference to same project to itself. So when 
    I removed self reference, it worked. 
4

Come da Error: Cannot access file bin/Debug/… because it is being used by another process answer by TarmoPikaro, a volte Visual Studio crea più processi fantasma MSBuild.exe, che persistono dopo build. Questi processi fantasma sembrano causare blocchi di file.

Soluzione 1 - Uccidete il fantasma di MSBuild.exe

Uccidere MSBuild.exe di una soluzione una volta, deve essere fatto per la base di build.

Si può uccidere i processi come segue mrtumnus:

taskkill/f/im MSBuild.exe

Soluzione 2 - Disabilitare parallelo costruisce in Visual Studio

È possibile disattivare costruire in parallelo una volta per all:

Strumenti> Opzioni> Progetti e soluzioni> Crea ed esegui> "numero massimo di build di progetti paralleli": per impostazione predefinita ha valore 8, quindi passa a 1.

Ovviamente le build sono un po 'più lente ora, ma il chilometraggio può variare a seconda del caso d'uso.

questo è legato alla Error: Cannot access file bin/Debug/... because it is being used by another process

Problemi correlati