c# - studio - Error de compilación: "El proceso no puede acceder al archivo porque lo está utilizando otro proceso"
windows forms c++ visual studio 2017 (20)
Tengo una aplicación de webforms C #, que hasta el día de hoy había estado funcionando a la perfección.
Hoy, de repente, cada vez que intento ejecutar la aplicación, aparece un error de bloqueo de archivos:
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 lo está utilizando otro proceso.
Buscar en Google el error no viene más allá de lo obvio, es decir, VS cree que el archivo está bloqueado. Y definitivamente es el propio Visual Studio el que bloquea el archivo, porque cuando cierro VS y lo vuelvo a abrir, el proyecto se ejecuta correctamente, 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 evito que se bloquee?
EDITAR: Otro descubrimiento interesante: ni siquiera tengo que ejecutar la aplicación. Solo compilarlo una vez causa 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 encerra.
¿Cómo se configura su aplicación web? ¿Funciona bajo Cassini (el servidor web de bandeja) o IIS?
Esto no debería suceder normalmente sin embargo. Creo que ProcessExplorer puede decirle qué archivos ha bloqueado un proceso. Si no se trata del explorador, una de las otras herramientas de sysinternals.
Una cosa que debes probar antes de descargar una de las herramientas SI es detener el servidor web Cassini y ver si eso libera el archivo.
Bueno, yo mismo resolví el problema, aunque todavía no tengo idea de por qué. Decidí aislar el problema eliminando todos los archivos del proyecto, luego volviéndolos a agregar y determinando de qué manera el archivo fue el origen de mi problema. Entonces, uno por uno volví a introducir los archivos en el proyecto, los compilé y los limpié en cada paso del camino ... hasta que ... agregué el último ...
... y todo funcionaba bien.
Hice una comparación con el control de fuente de mi .csproj original; no hay 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é, solo acéptalo y sigue adelante ...
EDITAR: El problema es recurrente, y creo que lo he aislado cuando tengo el diseñador de formularios abierto de un formulario abstracto / genérico en tiempo de 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, debes cerrar VS y volver a abrir.
De hecho, debería querer 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" if exist "$ (TargetPath)" si no existe "$ (TargetPath) .locked" move "$ (TargetPath)" "$ (TargetPath) .locked "
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 baja y he aquí que ya no estaba marcada.
También tenga en cuenta que -app-vshost.exe se ejecuta en segundo plano aunque no esté depurando. Que es lo que lo hace construir y ejecutar con éxito cada vez que lo creo. No estaba funcionando antes. Y también traté de limpiar las carpetas de depuración y liberación y cambiar el tipo de objetivo constantemente y nada funcionó, excepto como se describe anteriormente. Mi solución antes era solo esperar 5 minutos entre compilaciones, lo que se volvió muy molesto y requería mucho tiempo para hacer algo. No he visto ningún cambio en el comportamiento en el que importaba qué pestañas estaban abiertas o XNA frente a las ventanas formadas o los diseñadores que se abren. Este problema ocurrió en compilaciones de 32 bits o de 64 bits y no importó si eliminé una aplicación con ALT-F4 o la eliminé con el administrador de tareas, lo que, en teoría, no permitiría que la aplicación cerrara o liberara recursos. Al principio pensé que era un problema de recolección de basura.
Ejecute este comando desde el cuadro Ejecutar:
net stop iisadmin /y
y entonces
iisreset
trabajó para mi. vs 2003
En mi caso, se estaban ejecutando algunos procesos vstest (con varios nombres pero todos contenían la cadena vstest). Tuve que terminarlos en taskmgr.
He encontrado una solución simple que funciona para mí. Dice así:
Cuando se produce el problema, simplemente cambie la configuración del edificio en la parte superior (si está en "Liberar" a "Depurar" y viceversa), compilar y luego volver a la configuración anterior y volver a compilar.
Supongo que al cambiar la configuración se lanzan vcshost y devenv.
He superado este problema cambiando el nombre del archivo bloqueado (usando Windows Explorer). No se me permitió borrar el archivo, pero cambiar el nombre del archivo bloqueado funciona.
Lo que funcionó para mí fue reiniciar IIS
Lo que hemos descubierto aquí es lo siguiente: en la página de propiedades del proyecto, pestaña Depuración, desmarque la casilla "Habilitar el proceso de alojamiento de Visual Studio". No estoy seguro para qué es esta propiedad, pero hace el trabajo una vez sin marcar.
Lo resolví eliminando la carpeta bin / Debug y, posiblemente, reiniciando VS
Mismo error, resuelto al actualizar los paquetes de soporte de Google Nuget
Para mí, fue un servicio de Windows que se instaló y ejecutó. Una vez que lo detuve, la construcción fue exitosa.
Poco tarde para responder, pero lo resuelvo yendo a las propiedades del proyecto> pestaña "Depurar"> desmarque "Habilitar el proceso de alojamiento de Visual Studio".
Recientemente me encontré con este problema cuando intento construir una solución en la que estoy trabajando (no solo un proyecto de winforms).
Además de la falla de build , noté que los proyectos de limpieza fallaban silenciosamente (comprobar que la carpeta bin mostraba que los archivos no se habían borrado realmente) y cerrar Visual Studio no terminaba el proceso devenv , sino que hacía que se bloqueara. El proceso de recuperación de Windows reiniciaría Visual Studio.
Después de un poco de prueba y error, descubrí que los problemas solo me sucedieron cuando abrí la solución del menú "Reciente" al iniciar VS.
Al abrir la solución desde File >> Open >> Project/Solution encontró trabajando normalmente.
Actualmente no tengo idea de por qué, seguiré investigando esto, pero por ahora, ¡al menos puedo trabajar!
Simplemente revise 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 relacionado con el control personalizado y el problema aún permanecía, hasta que revisé las referencias y se estaba refiriendo a sí mismo para poder "obtener" el control personalizado anterior. ¡Eliminé la referencia y lo hice!
Solo para arrojar 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, no hay ui, nada), pero no estoy seguro de por qué sucedió esto. Obviamente, el depurador no se estaba ejecutando y solo tenía una instancia única de VS abierta en ese momento. Me sorprende que esto todavía esté sucediendo en este VS 2017.
Quizás pueda agregar un paso de compilación que busque la aplicación que ejecuta el fondo y lo mate antes de comenzar el nuevo.
Tuve dos instancias de Visual Studio que abrieron la misma solución.
Tuve el mismo problema en mi aplicación Xamarin en Visual Studio y se resolvió desenchufando mi dispositivo móvil de prueba. La aplicación se cerró y el depurador se detuvo, pero el error todavía estaba sucediendo al intentar compilar o reconstruir la solución. Solo se detuvo después de desconectar el dispositivo porque tenía que recibir una llamada.
VS2017: se resolvió cerrando todas las instancias de MSBuild.exe en el administrador de tareas de Windows
tuve este mismo problema también. cambiar la configuración de depuración / liberación no funcionó. al menos no sin construir en el medio.
en mi solución (winform) fue resuelto abriendo la forma principal de winform en el diseñador. cambiando al código (F7). A continuación, cierre el código, cierre el diseñador de winform y reconstruya todo (ctrl-shift-B). Esto funcionó para mí.
Parece que hay algún tipo de identificador dentro de la aplicación winform (que ejecuta un backgroundworker) que aún tenía un identificador de archivo en algunas de las otras bibliotecas utilizadas.