visual studio - studio - Error: no se puede acceder al archivo bin/Debug/... porque está siendo utilizado por otro proceso

visual studio code español (24)

Cuando depuro mi proyecto, obtengo el siguiente error:

"No se puede copiar el archivo" obj / Debug / My Dream.exe "a" bin / Debug / My Dream.exe ". El proceso no puede acceder al archivo" bin / Debug / My Dream.exe "porque lo está utilizando otro proceso."

Utilizando Process Explorer, veo que MyApplication.exe estaba fuera, pero el proceso del sistema todavía lo usa aunque detuve la depuración antes. Cada vez que cambio mi código y comienzo a depurarlo, va a suceder. Si copio el proyecto a USB y la depuración, se ejecutará correctamente.

¿Por qué? ¿Cómo puedo solucionar este error?

Yo uso Window 7 Professional. Con Xp nunca he tenido este error.

Al menos en mi caso, he notado que visual studio 2012 estaba creando al menos dos procesos fantasma msbuild.exe, que no perecieron después de la compilación. Estos zombies aparentemente están causando que aparezcan bloqueos de archivos.

La eliminación de msbuild.exe es una solución única, debe hacerse por cada compilación.

Pero luego me di cuenta de que podía deshabilitar la compilación paralela de una vez por todas: ingresé en Herramientas> Opciones> Proyectos y soluciones> Compilar y ejecutar> "Números máximos de compilaciones de proyectos paralelas" - por defecto tiene valor de 8, Cambié a 1. Funciona como encanto.

Por supuesto, las construcciones son ahora un poco más lentas, pero es mejor prevenir que lamentar. Al menos para este pequeño proyecto en particular, no necesitaba más de un hilo de construcción.

Asegúrese de que cualquier ejecución anterior de la aplicación (por ejemplo, la opción de inicio sin depuración) esté realmente detenida. Estaba trabajando en una aplicación WPF, comencé sin depuración y la reduje al mínimo cuando recibí el error. Después de cerrar la aplicación, el comportamiento de VS volvió a la normalidad.

Cierre VisualStudio, ctrl-alt-delete, seleccione el Administrador de tareas, busque y finalice todos los procesos de MSBuild. VisualStudio básicamente tiene un error bastante grave en el que pierde el control de su depurador y el depurador mantiene un bloqueo en el archivo .pdb en la depuración / bin carpeta. Después de finalizar todos los procesos de MSBuild (depurador), elimine la carpeta / debug / bin y vuelva a abrir su solución en Visual Studio. Eres bueno para ir ahora. Microsoft necesita arreglar esta mierda.

Comando de precompilación

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

Ayudado

Computadora (clic con el botón derecho) -> administrar -> Servicio y aplicación -> servicio -> Habilitar experiencia de aplicación

¡Trabajó para mi!

En mi caso fue que habilité "Mostrar todos los archivos". Visual Studio 2017

Esto es pura especulación, y no una respuesta.

Sin embargo, he tenido este problema por un tiempo.

Llegué después de un tiempo para sospechar una interacción entre VS y mis precauciones AV.

Después de tocar un poco, parece que puede haber desaparecido cuando modifiqué mi antivirus para que todo lo que estaba debajo

C: / Users [nombre de usuario] / AppData / Local / Microsoft / VisualStudio / 10.0 / ProjectAssemblies

la carpeta no estaba incluida en la protección en tiempo real.

Parece que la compilación en realidad escribe la DLL aquí primero, luego la copia a la ubicación de compilación final.

He abierto una pregunta separada con respecto a VS 2017 que tuvo un comportamiento similar después de una actualización. El problema parecía ser generado por el programa antivirus, aunque.

He agregado la carpeta bin a la lista de exclusión de antivirus, reinicié la máquina y ahora parece funcionar.

He corrido a este mismo problema, y lo que encontré es que en realidad están ejecutando varias aplicaciones de Windows en segundo plano. Sucede cuando su aplicación tiene dos formularios y cierra el segundo formulario, que no es su formulario principal, por lo que la aplicación no saldrá por completo.

Suelo ejecutar mi aplicación

a través de su exe o
ejecutar sin depurar

La solución está cerca de la otra instancia de la aplicación de formulario de Windows . Esta es one forma de cerrar siempre la instancia de la aplicación.

He encontrado la manera más rápida sin cerrar formularios o reiniciar VisualStudio ir a la página de compilación del proyecto y hacer clic en el botón "Opciones de compilación avanzadas ...". Luego realice cualquier cambio en una de las opciones (digamos, cambiando Generar información de depuración de completa a pdb-only), luego haga clic en Aceptar. Funciona todo el tiempo y tendrá que hacerlo hasta que MS corrija este error (nunca he tenido este problema hasta que cambié de VS2012 a VS2013)

Otra nota, si no puede limpiar el proyecto o la solución, no se compilará. Los archivos definitivamente están bloqueados por VS (no es un problema de antivirus, al menos no en mi caso)

He estado plagado por este problema en Visual Studio 2017. Comenzó hace dos o tres semanas, y ha afectado severamente mi productividad. Clean y Rebulid no han funcionado; incluso reiniciar mi máquina no hace el trabajo.

Una forma de resolver el problema es limpiar el ensamblaje ofensivo y construir (en lugar de reconstruir) el proyecto que desea ejecutar inmediatamente después. Esto funciona aproximadamente el 30% del tiempo.

Sin embargo, probablemente la solución más confiable que he encontrado es abrir un símbolo del sistema de desarrollador y usar msbuild directamente. He estado haciendo esto durante los últimos tres días, y hasta ahora el problema no ha sucedido una vez.

He tenido este error antes, incluso en Visual Studio 2008. Regresó y prevaleció más en Visual Studio 2012.

Esto es lo que hago.

Pegue esto en el evento de precompilación del proyecto problemático:

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

Mi problema era que dotnet se colgó y cada vez que VS intentaba crear un dll nuevo, o acceder a uno antiguo, el proceso de dotnet se enganchaba al dll y evitaba que visual studio clonara el dll. La solución es simplemente finalizar todas las tareas de dotnet en el administrador de tareas (solo eliminará el que está muerto, si está tratando de finalizarlo y no se apagará, eso significa que está funcionando).

Otro desafío, ugh, pero es fácil y funciona para mí en VS 2013. Haz clic en el proyecto. En el panel de propiedades debe haber una entrada llamada Project File con un valor

(el nombre de tu proyecto) .vbproj

Cambie el nombre del proyecto, como agregar un -01 hasta el final. El archivo .zip original que estaba bloqueado todavía está allí, pero ya no se hace referencia ... para que su trabajo pueda continuar. La próxima vez que reinicie la computadora, esa cerradura desaparecerá y podrá eliminar el archivo errante.

Podría ser demasiado tarde. Pero, me encontré con un problema similar y en mi caso el proyecto tenía referencia propia. Por lo tanto, eliminarlo de las referencias funcionó como un encanto!

Probé todas estas sugerencias, así como otras sugerencias encontradas en otros lugares y lo único que funcionó para mí fue reiniciar mi computadora. Luego hice una solución limpia seguida de una reconstrucción. Estoy usando Visual Studio 2013 como referencia.

Recientemente, tuve un problema con Visual Studio 2012 con la misma descripción de error: "El proceso no puede acceder al archivo porque lo está usando otro proceso ..."

Para arreglar esto primero, debe comprender la aplicación que aún la usa. Apagué todos los procesos como "MSBuild" y "MSBuild host". Pero esto no es suficiente. Si instaló "Contratos de código" y lo activó, a veces se necesitan los archivos DLL para verificar y colgar esta operación.

Por lo tanto, debe detener todos los procesos de "CCCheck.exe" y eso es todo.

Finalmente, para comprender que el proceso está usando su DLL, siempre puede intentar simplemente Eliminar la carpeta "obj" en su Administrador de Archivos y esta operación fallará, puede ver la "Ventana de Mensajes" con la descripción de la operación de suspensión. Además, como una variante, puede intentar usar la aplicación "Sys Internals Suite".

Trabajó para mi. Administrador de tareas -> Nombre del proyecto -> Finalizar tarea. (tuve 3 mismos procesos con el nombre de mi proyecto);

VS 2013; Win 8;

Tuve el mismo problema en Visual Studio 2013. No estoy seguro de qué causó esto en mi proyecto, pero pude solucionarlo limpiando la solución y reconstruyéndola.

Build> Clean Solution
Build> Rebuild Solution

Uf, este es un viejo problema, algo que aún aparece en Visual Studio de vez en cuando. Me ha mordido un par de veces y perdí horas reiniciando y peleando con VS. Estoy seguro de que ha sido discutido aquí en SO más de una vez. También se ha hablado en los foros de MSDN. No hay una solución real, pero hay un par de soluciones. Comience a investigar aquí .

Lo que sucede es que VS adquiere un bloqueo en un archivo y luego no lo libera. Irónicamente, ese bloqueo evita que VS mismo elimine el archivo para que pueda volver a crearlo cuando reconstruya la aplicación. La única solución aparente es cerrar y reiniciar VS para que libere el bloqueo en el archivo.

Mi solución original fue abrir la carpeta bin / Debug y renombrar el ejecutable. No puede eliminarlo si está bloqueado, pero puede cambiarle el nombre. De modo que puede agregar un número al final o algo así, lo que le permite seguir trabajando sin tener que cerrar todas sus ventanas y esperar que se reinicie VS. Algunas personas incluso han automatizado esto utilizando un evento de preconstrucción para agregar una cadena aleatoria al final del nombre de archivo de salida anterior. Sí, este es un truco gigante , pero este problema se vuelve tan frustrante y debilitante que harás cualquier cosa.

Más tarde descubrí, después de un poco más de experimentación, que el problema parece surgir solo cuando construyes el proyecto con uno de los diseñadores abiertos. Entonces, la solución que me ha funcionado a largo plazo y me ha impedido volver a tratar con uno de esos errores tontos es asegurarme de cerrar siempre todas las ventanas del diseñador antes de crear un proyecto de WinForms. Sí, esto también es un poco inconveniente, pero es seguro que los pantalones tengan que reiniciar VS dos veces por hora o más.

Supongo que esto también se aplica a WPF, aunque no lo uso y no he experimentado personalmente el problema allí.

Tampoco intenté reproducirlo en VS 2012 RC. No sé si ya se ha arreglado allí o no. Pero mi experiencia hasta el momento ha sido que todavía se las arregla para aparecer incluso después de que Microsoft haya afirmado haberlo resuelto. Todavía está ahí en VS 2010 SP1. No digo que sus programadores sean idiotas que no saben lo que hacen, por supuesto. Me imagino que hay múltiples causas para el error y / o que es muy difícil reproducirlo de manera confiable en un laboratorio. Esa es la misma razón por la que no he registrado personalmente ningún informe de fallos (aunque he +1 a otras personas), porque parece que no puedo reproducirlo de manera confiable, como el Abominable muñeco de nieve.

_{<end rant que está dirigido a nadie en particular>}

Una solución simple es ir a la carpeta bin / Debug, eliminar todos los archivos en esa carpeta y luego reconstruir. Si no funciona, cierre Visual Studio y luego vaya a la carpeta bin / Debug usando el explorador de archivos, en el coner izquierdo, haga clic en Archivo> Abrir símbolo del sistema> Abra el indicador de comando como administrador> Ingrese este comando "DEL / F / Q / A * "> luego reconstruir

Vea mi respuesta here si tiene este problema al ejecutar pruebas unitarias. Respuesta copiada a continuación:

Sobre la base de la respuesta de Sébastien, agregué un paso previo a la construcción de mi proyecto de prueba para matar automáticamente cualquier ejecutable vstest.* . El siguiente comando de precompilación me funcionó:
taskkill /f /im vstest.* exit 0
El comando exit 0 está al final para evitar fallas de compilación cuando no hay ejecutables vstest.* .

encontré la respuesta de Cody Gray parcialmente útil, ya que me dirigió a la fuente real de mi problema que algunos de ustedes también pueden estar experimentando: la ejecución de prueba de Visual Studio permanece abierta por defecto y mantiene un bloqueo en los archivos.

Para detener ese comportamiento predominantemente inútil, siga las instrucciones de https://connect.microsoft.com/VisualStudio/feedback/details/771994/vstest-executionengine-x86-exe-32-bit-not-closing-vs2012-11-0-50727-1-rtmrel

Desmarque el menú Prueba -> Configuración de prueba -> "Mantener ejecutándose el motor de ejecución de prueba"

Error [Solucionado]: no se puede acceder al archivo bin / Debug / ... porque está siendo utilizado por otro proceso:

Me estoy acercando a que obtienes este error mientras intentabas ejecutar dos ventanas de forma consecutiva, como cargar primero un formulario y luego, a veces, desaparecerá automáticamente y el segundo formulario se cargará en la pantalla.

Básicamente, debe cerrar su primer formulario que se ejecuta en segundo plano y la razón principal detrás de este error.

Para cerrar el primer formulario, debe agregar estas dos líneas de código en el segundo controlador de evento de carga de formulario.

Form1 form = new Form1(); form.Close();

Esto resolverá el error perfectamente.