Error de compilación: "El proceso no puede acceder al archivo porque está siendo utilizado por otro proceso"

Tengo una webformsaplicación de C # , que hasta hoy ha estado funcionando a la perfección.

Ahora, hoy, de repente, cada vez que intento ejecutar la aplicación, aparece un error de bloqueo de archivo:

No se puede copiar el archivo "obj \ Debug \ MyProject.exe" a "bin \ Debug \ MyProject.exe". El proceso no puede acceder al archivo "bin \ Debug \ MyProject.exe" porque está siendo utilizado por otro proceso.

Buscar en Google el error no produce nada más allá de lo obvio, es decir, VS piensa que el archivo está bloqueado. Y definitivamente es Visual Studio el que bloquea el archivo, porque cuando cierro VS y lo vuelvo a abrir, el proyecto se ejecuta bien, la primera vez. Cuando intento ejecutarlo por segunda vez, aparece el error de bloqueo del archivo.

¡Cerrar VS y volver a abrir cada vez que quiero ejecutar la aplicación no es una solución viable! ¿Cómo averiguo qué está bloqueando el archivo y cómo evito que se bloquee?

EDITAR: Otro descubrimiento interesante: ni siquiera tengo que ejecutar la aplicación. Compilarlo una vez provoca el bloqueo del archivo; ¡No puedo compilar dos veces seguidas!

Este problema es específico de un proyecto en mi solución. Todos los demás proyectos funcionan bien y se pueden ejecutar tantas veces como quiera. Es solo este proyecto el que se bloquea.

Encontré una solución simple que funciona para mí. Dice así:

Cuando ocurra el problema, simplemente cambie la configuración de construcción en la parte superior (si está en "Liberar" a "Depurar" y viceversa), compile y luego vuelva a la configuración anterior y compile de nuevo.

Supongo que cambiar la configuración libera vcshost y devenv.

Bueno, resolví el problema yo mismo, aunque todavía no tengo ni idea de por qué. Decidí aislar el problema eliminando todos los archivos del proyecto, luego volviéndolos a agregar y determinando de esa manera qué archivo era la fuente de mi problema. Entonces, uno por uno reintroduje archivos en el proyecto, compilé y limpié cada paso del camino ... hasta ... agregué el último ...

... y todo funcionó bien.

Hice una comparación con el control de fuente de mi .csproj original; sin diferencias reales. E incluso cuando intenté volver a la versión anterior de .csproj, todavía funcionó.

Magia negra. Si funciona, a veces es mejor no preguntar por qué, simplemente acéptelo y siga adelante ...

EDITAR: El problema es recurrente, y creo que lo he aislado cuando tengo al diseñador de formularios abierto de un formulario abstracto / genérico en el momento de la compilación.

Lección aprendida: asegúrese de que el Diseñador de formularios de cualquier formulario o control abstracto o genérico esté cerrado antes de compilar. Si no es así, ¡debes cerrar VS y volver a abrir!

Lo que hemos descubierto aquí es lo siguiente: En la página de propiedades del proyecto, pestaña Depurar, desmarque "Habilitar el proceso de alojamiento de Visual Studio". No estoy seguro de para qué sirve esta propiedad, pero hace el trabajo una vez que se desmarca.

En realidad, debería marcar "Habilitar el proceso de alojamiento de Visual Studio". Al menos para VS2010 de todos modos. Y también tengo:

si existe "$ (TargetPath) .locked" del "$ (TargetPath) .locked" si existe "$ (TargetPath)" si no existe "$ (TargetPath) .locked" mover "$ (TargetPath)" "$ (TargetPath) .bloqueado "

en las opciones de preconstrucción. Este problema me ha perseguido durante mucho tiempo y no fue hasta que John W. mencionó esta casilla de verificación que incluso me di cuenta de que existía y, por supuesto, ya estaba desmarcada.

También observe que -app-vshost.exe se ejecuta en segundo plano incluso cuando no se está depurando. Que es lo que hace que se compile y se ejecute con éxito cada vez, supongo. Antes no estaba funcionando. Y también intenté limpiar las carpetas de depuración y liberación y cambiar el tipo de destino constantemente y nada funcionó excepto como se describe anteriormente. Mi solución antes era esperar 5 minutos entre compilaciones, lo que resultaba muy molesto y consumía mucho tiempo para hacer cualquier cosa. No he visto ningún cambio en el comportamiento en lo que importaba qué pestañas estaban abiertas o se abrían XNA vs windows o los diseñadores. Este problema ocurrió en compilaciones de 32 bits o 64 bits y no importaba si mataba una aplicación con ALT-F4 o la mataba con el administrador de tareas, lo que, en teoría, no permitiría que la aplicación se cerrara o liberara recursos. Al principio pensé que era un problema de recolección de basura.

VS2017: resuelto cerrando todas las instancias de MSBuild.exe en el administrador de tareas de Windows

Un poco tarde para responder, pero soluciono esto yendo a las propiedades del proyecto> pestaña "Depurar"> desmarque "Habilitar el proceso de alojamiento de Visual Studio".

He superado este problema cambiando el nombre del archivo bloqueado (usando el Explorador de Windows). No se me permitió eliminar el archivo, ¡pero cambiar el nombre del archivo bloqueado funciona!

Resolví esto eliminando la carpeta bin \ Debug y, posiblemente, reiniciando VS

Para mí, era un servicio de Windows que estaba instalado y funcionando. Una vez que lo detuve, la compilación fue exitosa.

Ejecute este comando desde el cuadro Ejecutar:

net stop iisadmin /y

y entonces

iisreset

trabajó para mi. vs 2003

Recientemente me encontré con este problema al intentar construir una solución en la que estoy trabajando (no solo un proyecto winforms).
Además del builderror, noté que los proyectos de limpieza fallarían silenciosamente (al revisar la carpeta bin se mostró que los archivos no se habían borrado) y cerrar Visual Studio no finalizó el proceso.devenv proceso, sino que causó que se bloqueara. El proceso de recuperación de Windows reiniciaría Visual Studio.

Después de algunas pruebas y errores, descubrí que los problemas solo me sucedían cuando abrí la solución desde el menú "Reciente" al iniciar VS.
Al abrir la solución, la File >> Open >> Project/Solutionencontré funcionando normalmente.

Actualmente no tengo idea de por qué, seguiré investigando esto, pero por ahora, ¡al menos puedo trabajar!

Simplemente verifique las referencias y elimine la autorreferencia al proyecto.

Explicación: Mi problema comenzó después de crear un control personalizado y arrastrarlo y soltarlo en la paleta de la caja de herramientas para usarlo en formularios de diseño. Primero apareció una advertencia que decía que había una redundancia entre el archivo fuente de control personalizado (.cs) y el ejecutable del proyecto (.exe). Al ejecutar / depurar apareció el error: no se puede acceder al (.exe) porque se está utilizando (y era cierto).

Literalmente eliminé todo el código fuente con respecto al control personalizado y el problema persistió, hasta que revisé las referencias y se hacía referencia a sí mismo para poder "obtener" el control personalizado anterior. Eliminé la referencia y listo !!

Tuve el mismo problema en mi aplicación Xamarin en Visual Studio y se resolvió desconectando mi dispositivo móvil de prueba. La aplicación se cerró y el depurador se detuvo, pero el error seguía ocurriendo al intentar compilar o reconstruir la solución. Solo se detuvo después de que desconecté el dispositivo porque tenía que recibir una llamada.

Solo para tirar mis 2 centavos. Mi problema se resolvió abriendo el Administrador de tareas y matando la aplicación. Se estaba ejecutando en segundo plano sin ninguna indicación de que se estuviera ejecutando (ningún elemento en la barra de tareas, ninguna interfaz de usuario, nada), pero no estoy seguro de por qué sucedió esto. Obviamente, el depurador no se estaba ejecutando y solo tenía una instancia de VS abierta en ese momento. Me sorprende que esto siga sucediendo en este VS 2017.

Quizás pueda agregar un paso de compilación que busque la aplicación que se ejecuta en segundo plano y la elimine antes de iniciar la nueva.

Tuve el mismo problema y no pude solucionarlo utilizando ninguno de los métodos mencionados en las respuestas anteriores. Resolví el problema eliminando todas las instancias de "SSIS Debug Hist (32 bit)" en el administrador de tareas y ahora funciona con normalidad.

Eliminar la carpeta Obj, retail y debug del proyecto .NET y reconstruir nuevamente funcionó para mí.

¿Cómo está configurada su aplicación web? ¿Se ejecuta bajo Cassini (el servidor web de la bandeja) o IIS?

Sin embargo, esto no debería suceder normalmente. Creo que ProcessExplorer puede decirle qué archivos ha bloqueado un proceso. Si no procesa el explorador, una de las otras herramientas de sysinternals.

Una cosa que debe intentar antes de descargar una de las herramientas SI es detener el servidor web Cassini y ver si eso libera el archivo.

Lo que funcionó para mí fue reiniciar IIS

Yo también tuve este mismo problema. cambiar la configuración de depuración / liberación no funcionó. al menos no sin construir en el medio.

en mi solución (winform) se resolvió abriendo la forma principal de winform en el diseñador. cambiando al código (F7). Luego, cerrando el código, cerrando el diseñador de winform y reconstruyendo todo (ctrl-shift-B). Esto funcionó para mí.

Parece que algún tipo de identificador desde dentro de la aplicación winform (que ejecuta un backgroundworker) todavía tenía un identificador de archivo en algunas de las otras bibliotecas utilizadas.

Tenía dos instancias de Visual Studio que abrieron la misma solución.

En mi caso, se estaban ejecutando algunos procesos vstest (con varios nombres pero todos contenían la cadena vstest). Tuve que terminarlos en taskmgr.

Mismo error, resuelto actualizando los paquetes de soporte de Google Nuget

Cuando terminé el proceso .Net Core Host, todo salió bien. No tuve que cerrar Visual Studio ni cambiar nada más.

Para aquellos que están desarrollando en VS con Docker, reinicie la ventana acoplable para el servicio de Windows y el problema se resolverá de inmediato.

Antes de reiniciar Docker, probé todas las respuestas mencionadas, no encontré un proceso msbuild.exe ejecutándose, también intenté reiniciar VS sin resultado, solo reiniciar Docker funcionó.

Una solución más: cuando los archivos se bloquean, se informa del proceso de bloqueo (algo así como "ServiceHub.Host.CLR.x64 (7764)") con su identificación entre paréntesis. Para deshacerse del proceso, abra PowerShell (x + Win + I) y escriba: "Stop-Process -Id idNumber".

Recientemente me encontré con el problema al implementar en Service Fabric. El error implica que un 'archivo' está en uso, sin embargo, descubrí que el puerto estaba siendo utilizado por otro IDE. Al detener un servicio en ejecución que ya estaba alojado en el puerto, pude evitar que ocurriera esta excepción.

Me había enfrentado al mismo problema. Probé varias soluciones enumeradas anteriormente pero no funcionaron para mí.

Resolví este problema cerrando la conexión desde el Explorador de servidores y cerré todas las pestañas que estaban abiertas en Visual Studio.

Si se trata de un proyecto SSIS, abra el administrador de tareas y elimine todas las instancias de DtsDebugHost.exe, que deberían liberar los archivos bloqueados.

Utilizo Visual Studio Code y recibí este error porque el servidor de desarrollo se estaba ejecutando (ejecuté el servidor de desarrollo presionando Ctrl + F5 ).

Por lo tanto, simplemente hice clic en la señal de alto para detenerlo y el error desapareció.

Tuve este problema (y es un problema que he visto en otros lugares, no solo en VS).

Es causado por Dropbox (en mi caso). Después de editar algún código y presionar ejecutar, a veces Dropbox bloquea inmediatamente el archivo (para que pueda procesarlo).

Solución 1. Vuelva a pulsar ejecutar

Solución 2. Pause Dropbox. (no es bueno si usa Dropbox como copia de seguridad en la nube)

Solución 3. Elimine la carpeta de compilación de la lista de sincronización de Dropboxes.