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


113

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.


1
win7 a veces mantiene bloqueados los archivos que se ven en el explorador, así que asegúrese de no tener abierta la carpeta de depuración.
Necrolis

Creo que el proceso del sistema lo usa.
Trần Minh

1
Es un candado o algún idiota agregado / bin al control de código fuente, y ahora los archivos están protegidos contra escritura (haga clic con el botón derecho en bin, desmarque la opción protegida contra escritura).
Stefan Steiger

3
Esto es peor en Visual Studio 2017 que nunca.
Rob Lyndon

1
En mi caso, MSBuild.exetuve una retención en el archivo, simplemente finalice el proceso en el Administrador de tareas
Pierre

Respuestas:


120

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>


1
Esto todavía está sucediendo (para mí) en VS2013. Siempre es el archivo PDB para el proyecto WPF en mi solución el que se bloquea en el directorio de destino. Cerrar todos los diseñadores no funcionó (¡boo!), Pero cambiar el nombre del archivo sí (¡gracias, Cody!). Hack gigante llama ...
Jon

2
Esto comenzó a pasarme desde ayer cuando actualicé a vS 2013 ... esto no me había pasado una vez desde VS 2008 ... qué triste.
SomeNickName

8
VS 2015, y todavía tengo el problema.
Berin Loritsch

13
Está sucediendo en Visual Studio 17 y reiniciar Visual Studio no ayuda.
Rob Lyndon

2
@jairhumberto no hay motivo para el sarcasmo, las computadoras ya son lo suficientemente frustrantes, no es necesario que se lo comunique a otra persona ... pero esto me funciona para este problema específico, ¡tal vez esté teniendo algo diferente! Ver: stackoverflow.com/a/19649014/27494
ScottN

64

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"

1
¿Dónde puedo encontrar ese Pre-Buildevento en mi formulario de Windows?
Unknownymous

2
@qwerty Se encuentra en las propiedades del proyecto en la sección Eventos de compilación o si está en el proyecto VB.net, en la sección Compilar, verá un botón Eventos de compilación.
ScottN

@ScottN: oh, por cierto, este pre-buildcódigo también es el remedio para la aplicación implementada (a través de un clic una vez) cuando mi aplicación se está ejecutando, luego se produjo un error / falla y luego en el administrador de tareas, terminaré la tarea, myApp.exepero no FINALIZARÉ LA TAREA y aparecerá ERROR ON ENDING TASK?
Unknownymous

@qwerty No, esto no tiene asociación con una aplicación implementada ClickOnce. Este error es solo cuando está compilando su aplicación durante el desarrollo y las pruebas y solo en Visual Studio, no para ninguna aplicación implementada que se ejecuta en sistemas cliente.
ScottN

¿A qué se .lockedrefiere?
Shimmy Weitzhandler

22

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

¡Trabajó para mi!


2
Había desactivado este servicio hace unos meses. Habilitarlo ahora parecía resolver el problema en Visual Studio (no se puede copiar debido a que el archivo exe está bloqueado). Me pregunto por qué este servicio debe estar ejecutándose, lo que leí al respecto no parecía relacionado con nada relevante para este error (por ejemplo, blackviper.com/windows-services/application-experience ).
Andreas Jansson

10
Tengo este servicio en ejecución pero sigo teniendo el problema de bloqueo.
antfx

1
+1 Vaya, intenté / todo / lo demás que encontré. Finalmente tropecé con esto para solucionarlo. El mío también estaba desactivado. ¡Nunca hubiera pensado eso como culpable!
John S.

Ejecutar Windows 7 SP1 con VS2010 SP1, activar los servicios de "Experiencia de aplicación" me ayuda de inmediato. Muchas gracias. Pero un minuto después, apagarlo no reproduce el problema de inmediato.
Jimm Chen

7
servicio no encontrado en Windows 10
JerryGoyal

13

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

1
No lo intente en proyectos grandes ... La reconstrucción completa lleva mucho tiempo.
mBardos

7

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.


7

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.

ingrese la descripción de la imagen aquí


2

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.


1

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".


Al menos en mi caso, he notado que Visual Studio estaba creando procesos fantasmas msbuild.exe, que no perecieron después de la compilación. Estos zombis aparentemente están causando que aparezcan bloqueos de archivos. Pero no tengo ni idea de cómo solucionarlo. Matar msbuild.exe es una solución única, debe hacerse por compilación.
TarmoPikaro

1

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;


1

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.


1

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.


1

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


1

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


0

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.


0

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.


0

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)


0

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.


0

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.


0

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


0

[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.


0

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


0

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"


0

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).


0

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.


0

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.


0

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


-1

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.