La compilazione di Visual Studio non riesce: impossibile copiare il file exe da obj \ debug in bin \ debug


193

Aggiornamento: un progetto di esempio che riproduce questo errore è disponibile qui su Microsoft Connect . Ho anche testato e verificato che la soluzione fornita nella seguente risposta accettata funzioni su quel progetto di esempio. Se questa soluzione non funziona per te, probabilmente stai riscontrando un problema diverso (che appartiene a una domanda separata).


Questa è una domanda posta prima, sia qui su Stack Overflow che in altri luoghi, ma nessuno dei suggerimenti che ho trovato finora mi ha aiutato, quindi devo solo provare a fare una nuova domanda.

Scenario: ho una semplice applicazione Windows Form (C #, .NET 4.0, Visual Studio 2010). Ha un paio di moduli di base che la maggior parte degli altri moduli eredita, utilizza Entity Framework (e classi POCO) per l'accesso al database. Niente di speciale, niente multi-threading o altro.

Problema: tutto è andato bene per un po '. Quindi, all'improvviso, Visual Studio non è riuscito a creare quando stavo per avviare l'applicazione. Ho ricevuto l'avviso "Impossibile eliminare il file '... bin \ Debug \ [ProjectName] .exe'. L'accesso al percorso '... bin \ Debug \ [ProjectName] .exe' è negato." e l'errore "Impossibile copiare il file 'obj \ x86 \ Debug \ [ProjectName] .exe' in 'bin \ Debug \ [ProjectName] .exe'. Il processo non può accedere al file 'bin \ Debug \ [ProjectName] .exe "perché viene utilizzato da un altro processo". (Ricevo sia l'avvertimento che l'errore durante l'esecuzione di Ricostruisci, ma solo l'errore durante l'esecuzione di Build - non pensi che sia pertinente?)

Capisco perfettamente cosa dice l'avvertimento e il messaggio di errore: Visual Studio sta ovviamente cercando di sovrascrivere il file exe mentre allo stesso tempo ha un blocco su di esso per qualche motivo. Tuttavia, questo non mi aiuta a trovare una soluzione al problema ... L'unica cosa che ho trovato funzionante è chiudere Visual Studio e avviarlo di nuovo. La costruzione e il lancio quindi funzionano, fino a quando non faccio una modifica in alcuni dei moduli, quindi ho di nuovo lo stesso problema e devo ricominciare ... Piuttosto frustrante!

Come accennato in precedenza, questo sembra essere un problema noto, quindi ci sono molte soluzioni suggerite. Elencherò solo ciò che ho già provato qui, così le persone sanno cosa saltare:

  • Crea una nuova soluzione pulita e copia i file dalla vecchia soluzione.
  • Aggiungendo quanto segue all'evento pre-build del progetto:

    if exist "$(TargetPath).locked" del "$(TargetPath).locked"
       if not exist "$(TargetPath).locked" if exist "$(TargetPath)" move "$(TargetPath)" "$(TargetPath).locked"
  • Aggiungendo quanto segue alle proprietà del progetto (file .csproj):

    <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>

Tuttavia, nessuno di loro ha funzionato per me, quindi puoi probabilmente capire perché sto iniziando a sentirmi un po 'frustrato. Non so dove altro cercare, quindi spero che qualcuno abbia qualcosa da darmi! È un bug in VS, e se è così c'è una patch? O ho fatto qualcosa di sbagliato, ho un riferimento circolare o simile, e in tal caso come potrei scoprirlo?

Eventuali suggerimenti sono molto apprezzati :)

Aggiornamento: Come menzionato nel commento qui sotto, ho anche verificato usando Process Explorer che in realtà è Visual Studio che sta bloccando il file.


4
Hai controllato se la tua domanda si chiude correttamente? Il task manager ti mostra [ProjectName] .exe nell'elenco dei processi?
miensol,

2
Ho già avuto questo in precedenza e ho semplicemente rinominato il file in .old ecc. E ho eseguito nuovamente la build. Non esattamente una soluzione che conosco, ma ha funzionato per me.
codingbadger,

@miensol: Sì, sembra chiudersi correttamente. Ottengo "Il programma '[1848] [ProjectName] .vshost.exe: Managed (v4.0.30319)' è uscito con il codice 0 (0x0)." @Barry: rinominare il file exe in bin \ Debug funziona, ma come hai detto non è davvero una soluzione e sarà abbastanza fastidioso doverlo fare ogni volta. Un po 'meglio del riavvio di Visual Studio però ...
Julian,

2
@Naliluj: Mi sono imbattuto in questo articolo da un forum Microsoft che spiega che può essere correlato ai file di risorse. Se si utilizzano file resx, questo potrebbe dare un suggerimento.
Patrick,

1
Per i posteri, ho avuto questo problema ed è stato risolto aggiungendo l'elemento <GenerateResourceNeverLockTypeAssemblies> true </GenerateResourceNeverLockTypeAssemblies> al mio file csproj.
ThisIsTheDave,

Risposte:


117

Questo sembrerà stupido, ma ho provato tutte queste soluzioni, eseguendo VS2010 su Windows 7. Nessuno di loro ha funzionato tranne la ridenominazione e la costruzione, che era MOLTO noioso a dir poco. Alla fine, ho rintracciato il colpevole e ho difficoltà a crederci. Ma stavo usando il seguente codice in AssemblyInfo.cs ...

[assembly: AssemblyVersion("2.0.*")]

Questo è abbastanza comune, ma per qualche motivo, cambiando la versione in 2.0.0.0 le cose hanno funzionato di nuovo. Non so se è una cosa specifica di Windows 7 (l'ho usato solo per 3-4 settimane), o se è casuale, o cosa, ma lo ha riparato per me. Immagino che VS mantenga un controllo su ogni file che ha generato, quindi saprebbe come incrementare le cose? Non ne sono davvero sicuro e non ho mai visto succedere prima. Ma se qualcun altro là fuori sta anche strappando i capelli, provalo.


12
Questa è un'idea folle, te lo darò;) Ciò che è ancora più folle, è che sembra davvero funzionare! L'ho provato diverse volte e posso confermare che quando utilizzo una versione di assembly come "2.0. *" Ottengo l'errore, ma quando invece utilizzo "2.0.0" funziona come un incantesimo! Esorto più persone a provarlo e, se lo trovi funzionante, vota questa risposta, perché è qualcosa che deve essere conosciuto! Spero che Microsoft risponda a questo ... Grazie drharris :)
Julian,

2
questo non ha funzionato per me, quando ho riavviato VS non ho ricevuto errori per qualche tempo. Ogni volta che ricevo questo errore devo riavviare VS 2010
Sharique il

6
a proposito ... questo non ha funzionato per me. Le mie impostazioni sono sempre state: [assembly: AssemblyVersion ("1.0.0.0")] [assembly: AssemblyFileVersion ("1.0.0.0")]
tbone

4
Se al momento hai [assembly: AssemblyVersion ("1.0.0.0")], sostituiscilo con [assembly: AssemblyVersion ("2.0.0.0")] (ovvero "2" anziché "1"). Ha funzionato per me. Anche se non ho verificato, è possibile che semplicemente cambiando la versione con qualcosa di diverso da quello che hai ora in grado di risolvere questo problema.
Frederick The Fool,

1
Funziona anche per DLL! VS dice che non è possibile copiare la dll e dopo aver cambiato ENTRAMBI [assembly: AssemblyVersion] e [assembly: AssemblyFileVersion ()] da 1.0. * A 2.0.0.0, ha funzionato.
AZ.

14

Dal momento che non ho ricevuto più feedback su questo problema, ho pensato di condividere quella che alla fine è stata la mia soluzione:

Come suggerito da Barry in un commento al post originale, rinominando manualmente "... bin \ Debug [ProjectName] .exe" in qualcos'altro (ad esempio "[ProjectName] 1.exe" ) è una soluzione (I ' Tuttavia, non mi è permesso di eliminare il file da solo, e devo dire che trovo che sia un po 'strano poiché si potrebbe credere che lo stesso blocco che impedisce l'eliminazione impedirebbe anche la ridenominazione ...). Non è una buona soluzione, ma è abbastanza veloce (almeno dopo averlo fatto un paio di volte, diventa quasi una routine) e almeno molto più veloce del riavvio di Visual Studio, che è quello che ho fatto all'inizio.

Nel caso qualcuno si chieda, potrei anche aggiungere che vedo questo problema solo in modo semi-casuale. Di solito succede dopo che ho apportato alcune modifiche alla modalità di progettazione di un modulo (ma non sempre). Di solito non succede se cambio solo codice di business logic o codice non visivo (ma a volte lo fa ...). Davvero frustrante, ma almeno ho un trucco che funziona per me - speriamo solo che il mio prossimo progetto non affronti anche questo problema ...

@Barry: se desideri ottenere credito per il tuo commento, non esitare a pubblicarlo come risposta e mi assicurerò di accettarlo :)


L'ho votato perché è quello che ho fatto in passato. Sono d'accordo, è una soluzione sporca ma funziona. VS ha avuto questo problema per alcune iterazioni. Sto caricando il mio progetto anche da una directory di rete. È stato completamente attendibile, ma non importa. Non importa se si tratta di un mapping di unità o di UNC. Sì, MS ha davvero bisogno di risolvere questo. Hanno un bug chiuso perché non è in grado di riprodursi. Noioso!
Josh Robinson,

14

Ho trovato una soluzione semplice, basta disabilitare i servizi di indicizzazione di Windows per la cartella del progetto e le sottocartelle


2
Questo ha funzionato anche per me. Non sono sicuro di aver capito perché, come ha mostrato process explorer, devenv.exe teneva la maniglia di blocco. Tuttavia, la disattivazione dell'indicizzazione ha risolto il problema.
Fopedush,

1
@Fopedush Ho riscontrato questo problema con la stessa soluzione, anche se al momento non ho visto questa domanda. Questa risposta ha alcune spiegazioni sul perché aiuta.
Darren Hale,

1
Questo è stato per me.
Martin Capodici,

12

Ho lo stesso problema (MSB3021) con il progetto WPF in VS2008 (su Windows 7 x32). Il problema si presenta se provo a rieseguire l'applicazione troppo velocemente dopo l'esecuzione precedente. Dopo qualche minuto exe-file sbloccato da solo e posso rieseguire nuovamente l'applicazione. Ma una pausa così lunga mi fa arrabbiare. L'unica cosa che mi ha davvero aiutato era l'esecuzione di VS come amministratore.


1
Ho trovato questa recente segnalazione di bug su questo preciso problema: connect.microsoft.com/VisualStudio/feedback/details/558848/… Quella segnalazione di bug ha fornito un progetto di esempio in grado di riprodurre il bug. Anche la soluzione suggerita da Drharris ha funzionato lì (vedi la soluzione alternativa pubblicata nel link sopra per una soluzione dettagliata al progetto di esempio).
Julian,

Questa è l'unica soluzione che ha funzionato anche per me. Grazie @Nailuj!
Ala

Questo è sicuramente più semplice del riavvio di VS.
Elvedin Hamzagic,

1
"Pagina non trovata" per il problema di connessione, l'hanno semplicemente eliminata per imbarazzo = S C'è mai stata una soluzione / soluzione alternativa pubblicata per questo?
Coop il

9

Quando ho riscontrato questo problema, ha a che fare con il Fatto che il progetto che sto cercando di costruire è impostato come Progetto di avvio nella soluzione rendendo bloccato .exe nella cartella obj (appare anche nel task manager) fai clic con il pulsante destro del mouse su un altro progetto nella soluzione e scegli Imposta progetto di avvio. Questo rilascerà il blocco, lo rimuoverà dal task manager e dovrebbe lasciarti costruire.


1
Questo funziona ogni volta per me. Sembra avere a che fare con il processo vshost che viene generato e avviato per i servizi
jaywayco,

8

Ho provato tutti gli altri suggerimenti nelle risposte qui, nessuno dei quali ha funzionato. Alla fine ho usato Process Monitor per scoprire che il mio .exe che VS2010 non riusciva a costruire era bloccato dal processo di sistema (PID = 4). La ricerca di SO in situazioni che comportavano questo ha prodotto questa risposta.

Riassunto: se il servizio Esperienza applicazione è disabilitato (come ho fatto io), riattivare e avviarlo. Sono finiti due anni di aggravamento.


+1 In precedenza ho provato tutto il resto (1. task manager, 2. explorer di processo, ovvero gestione ravvicinata che Windows non mi lascia fare, 3. Disabilitazione antivirus, 4. esclusione di APP_DATA / Local / Microsoft / Visual Studio dal servizio di indicizzazione di Windows. ) ma questo consiglio è: il servizio "Application Experience" è l'unico che mi ha salvato sbattendo la testa contro il muro. L'ho abilitato e il problema è scomparso. La cosa divertente è che dopo che l'ho disabilitato di nuovo tutto era ancora OK. Non ho avuto più problemi. Ma sicuramente questa è l'unica cosa che l'ha risolto per me.
Tomás,

Lavora anche per me !!! L'unica altra cosa che funziona è anche eliminare la cartella bin prima di eseguire l'applicazione, ma è necessario eliminare sempre prima di eseguire, molto fastidioso.
E_Blue,

6

Ho anche avuto un problema molto simile a questo e ho scoperto che la ragione nel mio caso era che avevo reso disponibile la cartella bin \ debug come cartella condivisa in VMware e VMware, Explorer sotto il guest VM o forse anche un antivirus il programma sotto il guest (anche se non credo di averne installato uno) conteneva un handle per i file.


Ho installato Avast e stamattina ho ricevuto un errore MVC casuale che diceva che la mia DLL aveva un virus. Dopo l'errore, non ho più potuto costruire il mio progetto MVC. Ho aggiunto un'eccezione a Avast File System Shield e tutto funziona di nuovo.
Polveroso,


4

Suggerirei il download Process Explorerper scoprire esattamente quale processo sta bloccando il file. Si può trovare su:

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx


Sono d'accordo - non è necessariamente VS che blocca il file. I controllori di virus possono essere colpevoli di questo. Prova a disattivare il tuo antivirus per vedere se questo aiuta.
Polyfun,

Scusa, ho dimenticato di dire che l'ho già fatto. E dice che è Visual Studio (devenv.exe) che ha un blocco sul file ([ProjectName] .vshost.exe). Quindi neanche questo mi aiuta molto.
Giuliano,

@ShellShock: la disabilitazione del mio antivirus (Avast) non aiuta neanche.
Giuliano,

Per me, usando Sysinternals ProcessExplorer, posso vedere un handle per quel file, ma quando faccio clic su di esso, non viene mostrata alcuna applicazione che lo trattiene e quando provo a chiudere l'handle, ottengo un "Errore durante l'apertura del processo: l'handle è non valido." errore in ProcessExplorer. Eppure la serratura persiste ancora.
Data del

4

Utilizzando Visual Studio non sono mai riuscito a realizzare un semplice progetto per riprodurre l'errore.

La mia soluzione era disabilitare il processo di hosting di Visual Studio.

Per gli interessati ho allegato una traccia handle per l'handle offensivo:

0:044> !htrace 242C
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x000000007722040a: ntdll!ZwCreateFile+0x000000000000000a
0x0000000074b4bfe3: wow64!whNtCreateFile+0x000000000000010f
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0066: ntdll_773b0000!NtCreateFile+0x0000000000000012
0x000000007541b616: KERNELBASE!CreateFileW+0x000000000000035e
0x0000000075b42345: KERNEL32!CreateFileWImplementation+0x0000000000000069
0x000000006a071b47: mscorwks_ntdef!StgIO::Open+0x000000000000028c
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
*** WARNING: Unable to verify checksum for mscorlib.ni.dll
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x00000000000006cc, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130
0x0000000075b427b5: KERNEL32!RegOpenKeyExW+0x0000000000000021
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130

--------------------------------------
Parsed 0x358E stack traces.
Dumped 0x7 stack traces.
0:044> !handle 242c ff
Handle 242c
  Type          File
  Attributes    0
  GrantedAccess 0x120089:
         ReadControl,Synch
         Read/List,ReadEA,ReadAttr
  HandleCount   2
  PointerCount  3
  No Object Specific Information available

se vedi in cima alla domanda, c'è un collegamento a Microsoft Connect con una segnalazione di bug e un progetto di esempio che riproduce l'errore: connect.microsoft.com/VisualStudio/feedback/details/558848/…
Julian

Disabilitare il processo di hosting ha funzionato per me. Continua a funzionare anche dopo averlo riattivato. Ho trascorso 4 ore a cercare di risolvere questo problema provando centinaia di soluzioni. Questo è l'unico che sembra funzionare anche da remoto.
Ha disegnato Chapin il

4

SE IL TUO PROBLEMA NON È ANCORA RISOLTO:

L'errore di Visual Studio è:

"Il processo non può accedere al file 'bin \ Debug ** app.exe **' perché è utilizzato da un altro processo."

Quindi, vai al task manager di windows (Ctrl + Shift + Esc), trova il nome della tua applicazione e forzalo a chiudere con Endprocces.


3

Ecco un'altra possibilità:

Dopo aver ricevuto questo errore in vs2012 / win7, sono andato e ho cercato di eliminare il file nella directory bin ed explorer ha indicato che il file era in uso da XAML UI Designer.

Ho chiuso tutte le schede che avevo aperto in VS, chiuso VS, quindi mi sono assicurato di uccidere tutti i processi di MSBuild nel taskmanager. Alla fine, dopo aver riavviato VS, sono stato in grado di creare la soluzione.


e un'altra possibile causa:

Ho notato un'altra possibile causa per questo problema. Dopo aver eseguito il refactoring del codice, spostando i progetti dentro e fuori una soluzione, i riferimenti del mio progetto non facevano più riferimento ai progetti nella soluzione come previsto.

Questo studio visivo induce a pensare che potrebbe costruire alcuni progetti contemporaneamente, creando così i blocchi dei file.

EDIT: ho avuto questo accadere in alcune occasioni anche di recente con VS2012 e lo risolve una volta impostato l'ordine di compilazione sulle dipendenze corrette, ho ucciso tutti i processi msbuild che VS ha lasciato in esecuzione e quindi riavvia VS. Uccido i processi di msbuild solo per essere sicuro, ma chiudere VS dovrebbe anche ucciderli.

Quello che faccio di solito per causare questo è refactoring di un progetto in modo tale che si basi su un altro progetto all'interno della soluzione che non si riferiva all'ultima build. Questo a volte sembra confondere VS e non aggiorna l'ordine di costruzione.

Per verificare l'ordine di compilazione: fare clic con il pulsante destro del mouse sulla soluzione in Esplora soluzioni e selezionare "Ordine di compilazione progetto ..." e verificare che le dipendenze siano correttamente annotate per ciascun progetto.


Recentemente abbiamo sperimentato questo su un progetto WinPhone 8. Inspiegabilmente, la causa stava usando il tipo Tupla. Rimuovendo il codice che utilizzava una Tupla il problema è andato via. Aggiungi il codice indietro il problema restituito.
Seamus,

Ho avuto lo stesso problema con VS2012, chiudere VS non ha fatto il trucco - devo uccidere manualmente tutte le attività
msbuild.exe

Sto usando VS 2013 e sono stato in grado di uccidere il processo "XDesProc.exe * 32" (Progettazione dell'interfaccia utente XAML di Microsoft Visual Studio) nel task manager prima di ogni build e questo ha funzionato. Non è necessario riavviare VS perché il designer dell'interfaccia utente XAML sembra ricaricare ogni volta che si apre un file * .xaml in visualizzazione struttura.
Tim Sexton,

3

Riavvia IIS- potrebbe essere un processo collegato al debugger


3

Disabilita l'antivirus e prova. Stavo anche affrontando quel problema ... ma nel mio caso l'antivirus stava bloccando la mia applicazione quando ho disabilitato l'antivirus che si è risolto.


3

Ho riscontrato lo stesso errore.

Ho risolto il problema eliminando tutto il contenuto delle cartelle bin di tutti i progetti / librerie dipendenti.

Questo errore si verifica principalmente a causa di modifiche alla versione.



1

Prima fai le cose semplici.

Verificare che parte della soluzione non sia bloccata da un processo in esecuzione.

Ad esempio, ho eseguito "InstallUtil" sul mio servizio di Windows (che normalmente collaudo unità da una console).

Ciò ha bloccato alcune delle mie DLL nella cartella bin del progetto di servizio di Windows. Quando ho fatto una ricostruzione ho ottenuto l'eccezione in questo problema.

Ho interrotto il servizio di Windows, ricostruito e ci è riuscito.

Controlla Task Manager di Windows per la tua applicazione, prima di eseguire qualsiasi passaggio avanzato in questo problema.

Quindi, quando senti i passi, pensa ai cavalli e non alle zebre! (dall'amico studente di medicina)


1

Ho avuto lo stesso problema. Diceva che non poteva copiare da bin \ debug a obj .....

Quando ho creato un progetto web ho scoperto che la mia DLL era tutta nella cartella bin e non in bin \ debug. Durante la pubblicazione vs era alla ricerca di file in bin \ debug. Così ho aperto il file del progetto Web nell'editor e ho cercato le istanze di bin \ debug e ho scoperto che tutte le DLL erano menzionate come bin \ debug \ mylibrary.dll. Ho rimosso tutto \ debug dal percorso e pubblicato di nuovo. Questa volta vs è stato in grado di trovare tutte le DLL nella cartella bin e pubblicare con successo.

Non ho idea di come questo percorso sia stato modificato nel file di progetto web.

Ho trascorso più di 5 ore a eseguire il debug di questo e alla fine ho trovato la soluzione da solo.

Questa è la risposta giusta .


1

Se nessuna delle opzioni precedenti funziona e stai sviluppando un'applicazione console:

Prova a digitare qualsiasi carattere in Program.cs, quindi eliminalo. Non ho idea del perché funzioni, ma sembra risolvere il problema "Impossibile copiare" ogni volta.


1

Questo è piuttosto comunemente causato da Avast.

Di solito posso eseguire i miei progetti in Release a prescindere, ma durante l'esecuzione in debug fallirebbe regolarmente.

Aggiungo solo un'esclusione per la cartella dei miei progetti e il problema sembra scomparire. Presumo che ciò potrebbe essere causato anche da altri software antivirus.


1

Rinominare il file .exe e .pub ha funzionato per me, ma è davvero noioso. Devo anche affrontare il problema che non è stato possibile eseguire modifiche durante una sessione di debug. Infine sono andato alla pagina delle impostazioni di sicurezza avanzate, come da:

https://msdn.microsoft.com/query/dev10.query?appId=Dev10IDEF1&l=EN-US&k=k%28%22VS.ERR.DEBUG_IN_ZONE_NO_HOSTPROC%3a11310%22%29;k%28TargetFrameworkMoniker-%22.NETFRAMEWORK%2cVERSION % 3dV4.0% 22% 29 & rd = true

Deseleziono, quindi seleziono nuovamente la casella di controllo "Abilita impostazioni di sicurezza ClickOnce". È stato senza problemi per alcuni giorni ora ....


1

Per me questo è stato causato dalla presenza di un prompt dei comandi nella cartella target ( C:\users\username\source\repos\project\project\bin\debug\app.publish).

Non sono sicuro del motivo per cui DEBUGGING richiede l'accesso alla cartella di pubblicazione, ma la chiusura della finestra di comando ha risolto il problema per me.


1

Nel caso in cui qualcuno si stia imbattendo in questo mentre provava a eseguire il debug di un Unit Test o Esegui un unit test, ho dovuto interrompere i seguenti due processi per poter rilasciare il file:

processi per uccidere.


0

Ho provato diverse soluzioni fornite, ma a volte ricevo ancora questo errore. Sono sicuro che il mio processo non è in esecuzione e quando provo a eliminare il file eseguibile con Internet Explorer viene rimosso dall'elenco dei file, ma poi premo F5 e voilà, il file torna indietro. Non è stato affatto cancellato.

Ma se elimino il file tramite TotalCommander, il file exe viene effettivamente eliminato e posso creare correttamente il progetto.

Sto usando Windows 7 x64 e Total Commander 7.56a 32 bit.


0

Nessuna delle altre risposte ha funzionato per me, ma chiudere tutte le schede aperte in Visual Studio sembra aver risolto il problema.


0

So che questa è una domanda molto antica, ma di recente ho riscontrato l'errore "impossibile copiare da obj a bin" in VS 2012. Ogni volta che ho provato a ricostruire un determinato progetto, ho ricevuto il messaggio. L'unica soluzione era fare una pulizia prima di ogni ricostruzione.

Dopo molte ricerche, ho scoperto che in uno dei miei file avevo una dichiarazione di avvertimento pragma incompleta che non impediva il buon esito della compilazione, ma confondeva in qualche modo VS nel mantenere i file bloccati.

Nel mio caso, avevo all'inizio nella parte superiore del file:

#pragma warning(

Questo è tutto. Immagino che stavo tentando di fare qualcosa qualche tempo fa e mi sono distratto e non ho mai finito il processo, ma gli avvisi VS su quella particolare linea sono andati persi nel riordino. Alla fine ho notato l'avvertimento, rimosso la linea e ricostruito funziona da allora.


0

Quando ho affrontato un problema simile, l'unica cosa che sembrava funzionare era:

  • Fai clic con il pulsante destro del mouse sul progetto, vai su Impostazioni e assicurati che le build Debug e Release abbiano come target le stesse impostazioni o contengano le impostazioni che l'applicazione tenta di caricare o salvare.
  • Eliminazione della cartella C: \ Users (YourUserAccount) \ AppData \ Local (YourAppName).
  • Assicurandomi che nessun file che avevo lì fosse considerato "bloccato". Facendo clic con il pulsante destro del mouse sui file inclusi nel mio progetto, mi sono reso conto che un'icona era effettivamente bloccata e considerata errata perché è stata scaricata da Internet. Ho dovuto fare clic sul pulsante Sblocca (ad esempio, controlla questo: http://devierkoeden.com/Images/Articles/Dynamicweb/CustomModules/Part1/BlockedFiles.png - "Questo file proviene da un altro computer e potrebbe essere bloccato per aiutare proteggere questo computer. ").

0

Per i servizi Windows che utilizzano WCF, ho terminato il processo dell'host WFC e ha funzionato. Lo odio quando succede, e succede a volte a caso.


0

La mia soluzione non ha nulla a che fare con versioni, processi bloccati, riavvio o eliminazione di file.

Il problema era in realtà dovuto alla mancata compilazione e non alla visualizzazione dell'errore corretto. Il vero problema era un difetto di progettazione:

// Either this should be declared outside the function, or..
SomeObject a = new SomeObject(); 

Task.Factory.StartNew(() =>
{
   while (true)
   {
      a.waitForSomething();
   }
});

// ...this should not be called
a.doSomething(); 

Dopo aver modificato l'ambito di "a" all'esterno della funzione o non aver usato "a" dopo Task.Factory.StartNew();, sono stato in grado di ricostruire.

Ciò è accaduto quando si utilizza VS2012 Update 4 su Windows7x64 sp1.

Messaggio di errore:

C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Microsoft.Common.targets (3390,5): errore MSB3030: Impossibile copiare il file "obj \ x86 \ Debug \ xxx.exe" perché non è stato trovato .


0

Ho trovato con VS2013 ottengo questo errore regolarmente. Qualcosa che sembra funzionare abbastanza bene è eseguire una soluzione di ricostruzione prima di provare a eseguire l'applicazione. Ho scoperto che a volte eseguire un CLEAN funziona, ma la soluzione di ricostruzione sembra funzionare in modo più coerente.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.