Error: no se puede acceder al archivo bin / Debug / ... porque lo está utilizando otro proceso

Cuando depuro mi proyecto, aparece 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."

Usando Process Explorer, veo que MyApplication.exe estaba fuera, pero el proceso del sistema todavía lo usa, aunque dejé de depurar antes. Siempre que cambie mi código y empiece a depurar, sucederá. Si copio el proyecto a USB y depuro, se ejecuta bien.

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

Yo uso Windows 7 Professional. Con Xp nunca he recibido este error.

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

Lo que está sucediendo es que VS está adquiriendo un bloqueo en un archivo y luego no lo libera. Irónicamente, ese bloqueo evita que VS 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 del archivo.

Mi solución original fue abrir la carpeta bin / Debug y cambiar el nombre del ejecutable. No puede eliminarlo si está bloqueado, pero puede cambiarle el nombre. Entonces, puede agregar un número al final o algo así, lo que le permite seguir trabajando sin tener que cerrar todas las ventanas y esperar a que VS se reinicie. Algunas personas incluso han automatizado esto usando un evento previo a la compilación para agregar una cadena aleatoria al final del nombre del 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 me enteré, 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 abierto. Por lo tanto, la solución que me ha funcionado a largo plazo y me ha impedido volver a lidiar 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 algo inconveniente, pero seguro que es mejor que tener 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 he intentado reproducirlo en VS 2012 RC. No sé si lo han arreglado todavía o no. Pero mi experiencia hasta ahora ha sido que todavía se las arregla para aparecer incluso después de que Microsoft haya afirmado haberlo solucionado. Todavía está allí en VS 2010 SP1. No digo que sus programadores sean idiotas que no saben lo que hacen, por supuesto. Supongo que hay múltiples causas para el error y / o que es muy difícil de reproducir de manera confiable en un laboratorio. Esa es la misma razón por la que no he presentado personalmente ningún informe de errores al respecto (aunque he hecho +1 en otras personas), porque parece que no puedo reproducirlo de manera confiable, como el Abominable Snowman.

_{<fin, pero no se dirige a nadie en particular>}

Este error me ha aparecido antes, incluso en Visual Studio 2008. Regresó y fue más frecuente en Visual Studio 2012.

Esto es lo que hago.

Pegue esto en el evento de pre-construcción del proyecto problemático:

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

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

¡Trabajó para mi!

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.

1. Construir> Solución limpia
2. Construir> Reconstruir solución

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

Matar msbuild.exe es una solución única, debe hacerse por compilación.

Pero luego me di cuenta de que podía deshabilitar la compilación paralela de una vez por todas: fui a Herramientas> Opciones> Proyectos y soluciones> Compilar y ejecutar> "número máximo de compilaciones de proyectos paralelos": de forma predeterminada, tiene un valor de 8, yo he cambiado a 1. Funciona de maravilla.

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

Entiendo que esta es una vieja pregunta. Desafortunadamente, estaba enfrentando el mismo problema con mi .net core 2.0solicitud en visual studio 2017. Entonces, pensé en compartir la solución que funcionó para mí. Antes de esta solución, probé los pasos a continuación.

1. Estudio visual reiniciado
2. Cerró toda la aplicación
3. Limpiar mi solución y reconstruir

Ninguno de los pasos anteriores no solucionó el problema.

Y luego abrí mi proceso Task Managerseleccionado y luego hice dotnetclic en el botón Finalizar tarea. Más tarde abrí mi Visual Studio y todo estaba funcionando bien.

Vea mi respuesta aquí si tiene este problema mientras ejecuta pruebas unitarias. Respuesta copiada a continuación:

Sobre la base de la respuesta de Sébastien, agregué un paso previo a la compilación a mi proyecto de prueba para eliminar automáticamente cualquier vstest.*ejecutable que aún se esté ejecutando. El siguiente comando de compilación previa funcionó para mí:

taskkill /f /im vstest.*
exit 0

El exit 0comando está al final para evitar fallas de compilación cuando no hay vstest.*ejecutables en ejecución.

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

Para solucionar este problema, en primer lugar, debe comprender la aplicación que aún lo usa. He cerrado todos los procesos como "MSBuild" y "MSBuild host". Pero esto no es suficiente. Si instaló "Contratos de código" y los activó, a veces se necesitan sus 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 una descripción de la operación de bloqueo. Además, como variante, puede intentar utilizar 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; Gana 8;

Asegúrese de que cualquier ejecución anterior de la aplicación (por ejemplo, iniciar sin opción de depuración) esté realmente detenida. Estaba trabajando en una aplicación WPF, comencé sin depurar y lo minimicé cuando seguí recibiendo el error. Después de cerrar la aplicación, el comportamiento de VS volvió a la normalidad.

Este problema me ha afectado en Visual Studio 2017. Comenzó hace unas dos o tres semanas y ha afectado seriamente mi productividad. Clean y Rebulid no han funcionado; incluso reiniciar mi máquina no funciona.

Una forma de solucionar el problema es limpiar el ensamblado infractor y generar (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 para desarrolladores y usarlo msbuilddirectamente. He estado haciendo esto durante los últimos tres días y hasta ahora el problema no ha sucedido ni una vez.

En mi caso fue que tengo habilitado "Mostrar todos los archivos". Visual Studio 2017

Corre taskmanager.
Localícelo netcorey elimínelo.
A continuación, puede eliminar el archivo manualmente o ejecutando Clean.

Esto es pura especulación y no una respuesta.

Sin embargo, he tenido este problema durante un tiempo.

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

Después de jugar un poco, parece que puede haber ido lejos cuando he modificado mi antivirus para que todo bajo el

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

La carpeta no se incluyó en la protección en tiempo real.

Parece que la compilación realmente escribe la DLL aquí primero y luego la copia en la ubicación de compilación final.

Puede que sea demasiado tarde. Pero encontré un problema similar y, en mi caso, el proyecto tenía autorreferencia. Por lo tanto, eliminarlo de las Referencias funcionó de maravilla.

Encontré la manera más rápida sin cerrar formularios o reiniciar VisualStudio es 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 (por ejemplo, cambiar Generar información de depuración de Completo a solo pdb), luego haga clic en Aceptar. Funciona siempre y tendrá que hacerlo hasta que MS corrija este error (nunca tuve este problema hasta que cambié de VS2012 a VS2013)

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

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

Me encontré con este mismo problema, y ​​lo que encontré es que en realidad se están ejecutando varias aplicaciones de formularios de Windows en segundo plano. Sucede cuando su solicitud tiene dos formularios y cierra el segundo formulario, que no es su formulario principal, por lo que la solicitud no se cerrará por completo.

Normalmente ejecuto mi aplicación

• a través de su exe o
• ejecutar sin depurar

La solución es cerrar la otra instancia de la aplicación de formulario de Windows . Esta es una forma de cerrar siempre la instancia de la aplicación.

Comando previo a la construcción

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

Ayudado

[Resuelto] Error: No se puede acceder al archivo bin / Debug /… porque lo está utilizando otro proceso:

Me estoy acercando a que obtenga este error mientras intentaba ejecutar dos ventanas una tras otra, 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 controlador de eventos de carga del segundo formulario.

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

Esto solucionará el error a la perfección.

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, a la izquierda, haga clic en Archivo> Abrir símbolo del sistema> Abrir símbolo del sistema como administrador> Ingrese este comando "DEL / F / Q / A * "> luego reconstruir

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 la prueba de Visual Studio permanece abierta de manera predeterminada 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 el motor de ejecución de prueba en funcionamiento"

Mi problema era que dotnet se colgó y cada vez que VS intentaba crear una nueva dll o acceder a una antigua, el proceso de dotnet se enganchaba en la dll y evitaba que visual studio clonara la dll. La solución es simplemente finalizar todas las tareas de dotnet en el administrador de tareas (solo eliminará la que está muerta, si está tratando de finalizar una y no se apaga, eso significa que está funcionando).

Cierre VisualStudio, ctrl-alt-delete, seleccione 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 el debug / 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. Estás listo para irte ahora. Microsoft necesita arreglar esta mierda.

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

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

Resolví este problema ...

cerca de la depuración, verá el menú desplegable con alguna configuración. Por defecto había cualquier CPU. Seleccione x86 y ejecute el programa que funcionará. Si x86 no está allí, vaya al administrador de configuración y agregue el x86

Otro error, uf, pero es fácil y me funciona en VS 2013. Haz clic en el proyecto. En el panel de propiedades debe haber una entrada llamada Archivo de proyecto con un valor

(nombre de su proyecto) .vbproj

Cambie el nombre del proyecto, como agregar un -01 al 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, ese bloqueo desaparecerá y podrá eliminar el archivo erróneo.