Visual Studio “Imansible copiare” … durante la compilazione

Continuo a ricevere questo errore durante la creazione del mio progetto VS2012 C #

Error 41 Could not copy "obj\Debug\WeinGartner.WeinCad.exe" to "bin\Debug\WeinGartner.WeinCad.exe". Exceeded retry count of 10. Failed. Error 42 Unable to copy file "obj\Debug\WeinGartner.WeinCad.exe" to "bin\Debug\WeinGartner.WeinCad.exe". The process cannot access the file 'bin\Debug\WeinGartner.WeinCad.exe' because it is being used by another process. 

Ora ho capito che uccidere il processo

 Weingartner.WeinCad.vhost.exe 

funziona (a volte) ma questo mi sta dando sui nervi. Qualche modo per fermare tutto questo?

Le mie impostazioni del debugger sono

inserisci la descrizione dell'immagine quiinserisci la descrizione dell'immagine qui

Ho riscontrato messaggi di errore simili in Visual Studio 2013.

Per lo più, ho scoperto che questa situazione si è verificata quando un processo di debug è stato interrotto a causa di un’eccezione.

Quando clean + build non ha risolto questo problema per me, ho avuto successo nel fare quanto segue:

  • Chiusura di Visual Studio
  • Eliminazione del bin e delle cartelle obj e
  • Riaprire Visual Studio.

Questo “bug” esiste da Visual Studio 2003.

Infine, ho anche scoperto che posso spesso superare questo problema semplicemente rinominando il file eseguibile e quindi cancellandolo.

In Visual Studio Premium 2013 (Update 3), ho risolto questo problema con un one-liner pre-compilato:

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

Elimina con grazia tutti i vecchi file PDB (se ansible), quindi rinomina tutto ciò che è rimasto con estensione .old.pdb . Un bell’effetto collaterale è che se il vecchio PDB è ancora bloccato, aggiunge semplicemente un altro .old al nome del file, e tutti vengono ripuliti la prossima volta che riavvii Visual Studio e fai una compilazione.

Ad esempio, la sessione build / debug 1 lascia bloccato MyProject.pdb .
La prossima volta che costruisci:
MyProject.pdb -> MyProject.old.pdb

Quindi, viene avviata la sessione di compilazione / debug 2 e sia MyProject.pdb che MyProject.old.pdb sono ancora bloccati:
MyProject.old.pdb -> MyProject.old.old.pdb
MyProject.pdb -> MyProject.old.pdb

Infine, il riavvio di Visual Studio e la creazione di una nuova build elimineranno entrambi e continueranno il processo normalmente.

È perché hai chiuso la tua applicazione, ma è ancora in esecuzione in background.

Soluzione temporanea:

  • Vai a Task Manager ( Ctrl + Alt + Esc ).
  • Vai alla scheda Processi e trova “YourProjectName.exe”.
  • Seleziona “Mostra processi da tutti gli utenti” se non riesci a trovare il tuo processo.
  • Termina l’elaborazione.

Soluzione permanente: devi chiudere la tua applicazione tramite la codifica. Ecco il codice …

 System.Windows.Forms.Application.Exit(); 

Devi inserire questo codice nell’evento di chiusura del modulo in tutte le sue forms. Esempio:

 private void frm_menu_FormClosing(object sender, FormClosingEventArgs e) { System.Windows.Forms.Application.Exit(); } 

il .vhost.exe è un processo di debugger, quindi sembra che il processo in fase di debug non sia stato chiuso correttamente. È probabile che tu abbia un bug che lo tiene in vita e non interrompe correttamente il processo di debug – ci sono opzioni per staccarti dal processo quando fai clic su “arresta il debug” invece di uccidere effettivamente il debugger, quindi forse hai quel set.

Ma questo è il problema: il file che stai cercando di copiare è bloccato (cioè ancora in uso) dal sistema operativo, quindi impedisce la copia. Assicurati che il file sia gratuito e sarai in grado di copiare.

L’ho risolto uccidendo IISExpress nel task manager

Dovresti disabilitare il tuo antivirus (in particolare se si tratta di un Avast) e riprovare. Mi ha aiutato. Il problema è che il debugger / builder crea il file .exe identificato come una minaccia da Avast e quindi eliminato prima che potesse essere eseguito da VS.

Sono stato in grado di risolvere questo problema (VS 2010) fornendo le seguenti azioni pre-compilazione;

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

Citazione:

Una soluzione alternativa è di inserire questo nella proprietà della riga di comando dell’evento Pre-build del> progetto (nella scheda degli eventi di compilazione):

Snippet di codice

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

Uccidere il processo w3wp.exe (IIS) risolverà spesso questo problema.
In genere, è ansible conoscere il processo che ha il blocco sul file navigando nella cartella bin e cercando di eliminarlo. Il messaggio di errore che verrà visualizzato, nel caso in cui un altro processo lo stia utilizzando, conterrà il nome del processo che deve essere eliminato.

Eccezione

In alcuni casi in Visual Studio quando (Costruisci || Ricostruisci) sopra a IISExpress in esecuzione con questa Eccezione:

Imansible copiare il file “obj \ Debug \ YourProjectName.dll” in bin \ YourProjectName.dll. “Il processo non può accedere al file” bin \ YourProjectName.dll ” perché viene utilizzato da un altro processo

Soluzione

  1. Fai clic con il pulsante destro del mouse sul progetto web che deve essere creato.
  2. Clicca sulle proprietà.
  3. Seleziona la scheda Crea eventi sul lato sinistro.
  4. Nella riga di comando degli eventi pre-compilazione, incolla queste 2 righe:
 tasklist /fi "imagename eq iisexpress.exe" |find ":" > nul if errorlevel 1 taskkill /f /im "iisexpress.exe" 

Sei buono 2 GO!

Ho affrontato lo stesso problema su VS 2012 Version 11.0.60610.01 Update 3 su Windows 8

Non c’erano windows di progettazione aperte e il progetto era una semplice applicazione di console.

La rimozione del processo vshost che accede al file non funziona la maggior parte del tempo poiché il processo non sta accedendo al file.

La soluzione più semplice che funziona e richiede il minor tempo ansible è rimuovere il progetto dalla soluzione, creare un altro progetto nella soluzione e quindi aggiungere l’originale indietro.

È un irritante e una perdita di tempo, ma è la meno costosa di tutte le altre opzioni che conosco.

Spero che questo ti aiuti…

Penso di averlo risolto rimuovendo il segno di spunta per Break all processes when one process breaks nelle opzioni Debug (op primo screenshot-> seconda opzione).
Sta costruendo / funziona bene da un po ‘da quando l’ho deselezionato.
Uso i controlli MySql NET Connector e DevExpress nel mio progetto. Potrebbe essere che uno di loro non disponesse connessioni, legature, ecc. Perché questa bandiera è stata triggersta.

MODIFICATO: sicuramente funziona! Non più ‘Imansible copiare il file’ e non più errori di progettazione del form.

Sembra che, cambiando il nome dell’assembly di un progetto, si risolva il problema.

Quindi, invece di questo

inserisci la descrizione dell'immagine qui

Lo cambio a questo

inserisci la descrizione dell'immagine qui

Notare che l’ho appena cambiato da Increment and Recall a Increment_Recall , ho appena rimosso gli spazi. Ora sta funzionando bene per me.

Aggiungi nell’evento pre-build del tuo progetto principale taskkill / f / fi “pid gt 0” / im “YourProcess.vshost.exe”

Il mio contributo di 10 centesimi.

Ho ancora questo problema occasionalmente su VS 2015 Update 2.

Ho scoperto che il cambio di destinazione della compilazione risolve il problema.

Prova questo: se ti trovi in ​​DEBUG, passa a RELEASE e crea, quindi torna a DEBUG. Il problema è sparito.

Stefano

Soluzione: riavvia il sistema operativo, funziona sempre per me, poiché a volte il processo vshost non può essere terminato.

Questo bug esiste anche nelle versioni della serie VS incluso VS2013.

È ansible fare riferimento al collegamento: http://connect.microsoft.com/VisualStudio/feedback/details/533411

Non riesco a dare una soluzione per evitare che ciò accada, ma puoi almeno RINOMINARE il file bloccato (Windows Explorer o la classica finestra di comando) e quindi compilare / compilare. Non è necessario riavviare o riavviare VS201x. Con un po ‘di esperienza puoi aggiungere uno script pre-compilazione per cancellare vecchi file o rinominarli in modo che non ci siano nel caso in cui ci sia un blocco.

Vedi questa altra risposta . In sostanza, è ansible che i processi di MSBuild.exe siano in esecuzione in background e consumano file di risorse. Se si dispone di attività di pre o post build che causano l’avvio di un MSBuild tramite la riga di comando, provare ad aggiungere il flag “/ nr: false” a questo comando. Ma ancora, vedi la risposta precedente per dettagli più specifici.

La risposta di @ Geoff ( https://stackoverflow.com/a/25251766/3739540 ) è buona, ma genera il codice di errore 1 su ricompilare.

Ecco cosa ha funzionato per me (2> nul 1> nul alla fine + exit 0):

 (if exist "$(TargetDir)*old.pdb" del "$(TargetDir)*old.pdb") & (if exist "$(TargetDir)*.pdb" ren "$(TargetDir)*.pdb" *.old.pdb) 2>nul 1>nul (if exist "$(TargetDir)*old.dll" del "$(TargetDir)*old.dll") & (if exist "$(TargetDir)*.dll" ren "$(TargetDir)*.dll" *.old.dll) 2>nul 1>nul exit 0 

Se esegui il debug dei modelli T4 , questo accade sempre. La mia soluzione (prima che MS risolva questo) sarebbe solo quella di uccidere questo processo:

Task Manager -> Utente -> T4VSHostProcess.exe

Questo processo si verifica solo quando esegui il debug di un modello T4, non quando ne esegui uno.

  1. Aprire le proprietà del progetto [menu> progetto> proprietà]
  2. Scegli la scheda “debug”
  3. Deseleziona “Abilita il processo di hosting di Visual Studio”
  4. Avvia il debug [F5]
  5. Riceverai un avviso di sicurezza, solo “ok”. Consente l’esecuzione dell’applicazione
  6. Ferma il debug.
  7. Controlla l’opzione “Abilita il processo di hosting di Visual Studio”, nella scheda debug,
  8. Ora, prova ad avviare il debug, non vedrai più l’errore

[Lavora per me]

Segui i seguenti passaggi

  1. Apri Task Manager (Ctrl + Alt + Canc)
  2. Nella scheda Prestazioni selezionare selezionare < ProjectNameOfYours.exe >.
  3. Clicca su Termina processo.
  4. Ora costruisci la soluzione.

I passaggi precedenti hanno risolto l’errore in modo permanente 🙂

Se nessuna delle risposte funziona, prova questo semplice controllo. Trova qualsiasi MSbuild.exe in esecuzione e con il tuo progetto EXE. Uccidi MSBuild.exe e dovresti essere a posto.

Finalmente come aggiustarlo. Perché non possiamo continuare il debug dopo il primo debug perché il primo exe di debug è ancora in esecuzione. In modo che, dopo il primo debug, è necessario andare in Task Manager -> Elabora scheda -> [il nome del progetto exe] termina il processo exe.

per me funziona 🙂

Questa domanda era il primo risultato quando cercavi il seguente errore:

Imansible copiare il file “…” perché non è stato trovato.

durante la creazione in Visual Studio 2013 (aggiornamento 3).

Soluzione: disinstallazione di “Productivity Power Tools” in Visual Studio 2013.

https://connect.microsoft.com/VisualStudio/feedback/details/533411

Nel mio caso si trattava di Runner di Test unità di ricerca (più test NUnit, mai avuto problemi con MsTests). Dopo aver ucciso il processo, è stato in grado di ribuild il processo, senza riavviare il sistema operativo o VS2013

Non mi ero reso conto di avere ancora il mio debugger collegato e stavo cercando di creare nella stessa istanza di Visual Studio. Una volta ho fermato il debugger che ero in grado di build.

Uccidere il (i) processo (i) vstest.executionengine risolve questo problema il 90% delle volte per me. Se ciò non funziona, anche uccidere QTAgent32.exe e quindi eliminare le cartelle / bin e / obj per il progetto in questione funziona.

Questa è la parte più irritante della mia giornata di lavoro. 🙂

Per me è stato l’antivirus Avast che non consente a Visual Studio di scrivere / leggere / eseguire file. Quindi ho dovuto aggiungere la cartella Visual Studio 2010/2012 all’elenco di esclusione antivirus. E subito dopo baam … funziona.

Assicurati di chiudere tutte le istanze wcfSvcHost e riprovare. Ha funzionato per me!