Falla la compilación de Visual Studio: no se puede copiar el archivo exe de objdebug a bindebug

Encontré una solución simple, simplemente deshabilite los Servicios de Indexación de Windows para la carpeta y subcarpetas del proyecto

Dado que no he recibido más comentarios sobre este problema, pensé en compartir lo que terminó siendo mi solución:

Como lo sugirió Barry en un comentario al post original, renombrando manualmente el '...bin \ Debug[Nombre del proyecto].exe ' a otra cosa (por ejemplo, '[Nombre del proyecto] 1.exe') es una solución alternativa (sin embargo, no se me permite eliminar el archivo yo mismo, y debo decir que me parece un poco raro, ya que uno creería que el mismo bloqueo que impide la eliminación también evitaría cambio de nombre...). No es una buena solución, pero es razonablemente rápido (al menos después de haberlo hecho un par de veces, casi se convierte en una rutina), y al menos mucho más rápido que reiniciar Visual Studio, que es lo que hice al principio.

En caso de que alguien se pregunte, también podría agregar que solo veo este problema semi-aleatoriamente. Por lo general sucede después de que he hecho algunos cambios en el modo de diseño de un formulario (pero no siempre). Por lo general, no sucede si solo cambio el código de lógica de negocios o código no visual relacionado (pero a veces lo hace...). Frustrante de hecho, pero al menos tengo un truco que funciona para mí-esperemos que mi próximo proyecto no se enfrenta a este problema también...

@Barry: si desea obtener crédito por su comentario, no dude en publicarlo como respuesta y me aseguraré de aceptarlo:)

Tengo el mismo problema (MSB3021) con el proyecto WPF en VS2008 (en Windows 7 x32). El problema que aparece si intento volver a ejecutar la aplicación demasiado rápido después de la ejecución anterior. Después de unos minutos exe-archivo desbloqueado por sí mismo y puedo volver a ejecutar la aplicación de nuevo. Pero una pausa tan larga me enfurece. Lo único que realmente me ayudó fue ejecutar VS como Administrador.

Cuando me he encontrado con este problema tiene que ver con el Hecho de que el proyecto que estoy tratando de construir se establece como el proyecto de Inicio en la solución que hace el .exe en la carpeta obj bloqueada (también aparece en el administrador de tareas), haga clic con el botón derecho en otro proyecto de su solución y elija establecer proyecto de inicio. Esto liberará el bloqueo, eliminarlo del administrador de tareas y debería permitirle construir.

Probé todas las otras sugerencias en las respuestas aquí, ninguna de las cuales funcionó. Eventualmente usé Process Monitor para descubrir que mi .exe que VS2010 estaba fallando en la compilación fue bloqueado por el proceso del Sistema (PID=4). Buscando así situaciones que involucran esto dio esta respuesta.

Resumido: si tiene el servicio de Experiencia de aplicaciones deshabilitado (como lo hice yo), vuelva a habilitarlo e iniciarlo. Dos años de agravio terminaron.

También tuve un problema muy similar a este y encontré que la razón en mi caso fue que había hecho que la carpeta bin\debug estuviera disponible como una carpeta compartida bajo VMware y VMware, Explorer bajo el invitado de VM, o tal vez incluso un programa antivirus bajo el invitado (aunque no creo que tuviera uno instalado) estaba sosteniendo un controlador para el archivo(s).

Desactivar " Habilitar el proceso de alojamiento de Visual Studio"

SI SU PROBLEMA NO ESTÁ RESUELTO TODAVÍA:

El error de Visual studio es:

"El proceso no puede acceder al archivo 'bin\Debug**app.exe**' porque está siendo utilizado por otro proceso."

Entonces, vaya al administrador de tareas de Windows (Ctrl + Shift + Esc), encuentre el nombre de su aplicación y forzarlo a cerrar por Endprocess.

Usando Visual Studio nunca se me ocurrió un proyecto simple para reproducir el error.

Mi solución fue deshabilitar el proceso de alojamiento de Visual Studio.

Para los interesados he adjuntado un rastro de identificador para el identificador ofensivo:

0:044> !htrace 242C
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x000000007722040a: ntdll!ZwCreateFile+0x000000000000000a
0x0000000074b4bfe3: wow64!whNtCreateFile+0x000000000000010f
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0066: ntdll_773b0000!NtCreateFile+0x0000000000000012
0x000000007541b616: KERNELBASE!CreateFileW+0x000000000000035e
0x0000000075b42345: KERNEL32!CreateFileWImplementation+0x0000000000000069
0x000000006a071b47: mscorwks_ntdef!StgIO::Open+0x000000000000028c
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
*** WARNING: Unable to verify checksum for mscorlib.ni.dll
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x00000000000006cc, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130
0x0000000075b427b5: KERNEL32!RegOpenKeyExW+0x0000000000000021
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130

--------------------------------------
Parsed 0x358E stack traces.
Dumped 0x7 stack traces.
0:044> !handle 242c ff
Handle 242c
  Type          File
  Attributes    0
  GrantedAccess 0x120089:
         ReadControl,Synch
         Read/List,ReadEA,ReadAttr
  HandleCount   2
  PointerCount  3
  No Object Specific Information available

Aquí hay otra posibilidad:

Después de recibir este error en vs2012 / win7, fui e intenté eliminar el archivo en el directorio bin y el explorador indicó que el archivo estaba en uso por el Diseñador de interfaz de usuario de XAML.

Cerré todas las pestañas que tenía abiertas en VS, cerré VS, luego me aseguré de matar todos los procesos de MSBuild en taskmanager. Finalmente, después de reiniciar VS pude construir la solución.

Y otra posible causa:

Me he dado cuenta otra posible causa de este problema. Después de hacer un poco de refactorización de código, mover proyectos dentro y fuera de una solución, mis referencias de proyecto ya no hacían referencia a los proyectos en la solución como se esperaba.

Esto induce a error a visual studio a pensar que podría construir algunos proyectos simultáneamente, creando así los bloqueos de archivos.

EDIT: He tenido esto sucediendo en algunas ocasiones incluso recientemente con VS2012 y lo arregla una vez que establezco el orden de compilación en las dependencias correctas, mata cualquier procesos de msbuild que VS dejó en ejecución, y luego reiniciar VS. Mato los procesos de msbuild solo para estar seguro, pero cerrando VS debería matarlos también.

Lo que suelo hacer para causar esto es refactorizar un proyecto de tal manera que se basa en otro proyecto dentro de la solución que no estaba haciendo referencia en la última compilación. Esto a veces parece confundir a VS y no actualiza el orden de compilación.

Para comprobar el orden de compilación: Haga clic con el botón derecho en la solución en el Explorador de soluciones y seleccione " Project Build Orden..."y verificar que las dependencias estén debidamente anotadas para cada proyecto.

Restart IIS-podría ser un proceso adjunto al depurador

Desactivar antivirus y probar. Yo también me enfrentaba a ese problema... pero en mi caso antivirus estaba bloqueando mi aplicación cuando desactivé antivirus se resolvió.

Me enfrenté al mismo error.

Resolví el problema eliminando todo el contenido de las carpetas bin de todos los proyectos/bibliotecas dependientes.

Este error ocurre principalmente debido a cambios de versión.

Sugeriría descargar Process Explorer para averiguar exactamente qué proceso está bloqueando el archivo. Se puede encontrar en:

Http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

Esto se ha archivado varias veces en Connect, el sitio de informes de errores de la comunidad de Microsoft. Para tu información, creo que este error ha afectado a Visual Studio desde 2003 y se ha corregido después de RTM cada vez. : (Una de las referencias es la siguiente:

Https://connect.microsoft.com/VisualStudio/feedback/details/568672/handles-to-project-dlls-are-not-released-when-compiling?wa=wsignin1.0

Si nada de lo anterior funciona, y está desarrollando una aplicación de consola:

Intente escribir cualquier carácter en el Programa.cs, entonces bórralo. No tengo idea de por qué esto funciona, pero parece resolver el problema de 'No se puede copiar' cada vez.

Esto es causado comúnmente por Avast.

Generalmente puedo ejecutar mis proyectos en Release independientemente, pero cuando se ejecuta en debug fallaría bastante regularmente.

Simplemente agrego una exclusión para mi carpeta de proyectos y el problema parece desaparecer. Supongo que esto también podría ser causado por otro software antivirus.

Renombrar el .exe y .el archivo del pub funcionó para mí, pero realmente tedioso. También me enfrento al problema de no poder editar durante una sesión de depuración. Finalmente fui a la página de Configuración de Seguridad Avanzada, según:

Https://msdn.microsoft.com/query/dev10.query?appId=Dev10IDEF1&l=EN-US&k=k%28%22VS.ERR.DEBUG_IN_ZONE_NO_HOSTPROC%3a11310%22%29;k%28TargetFrameworkMoniker-%22.NETFRAMEWORK%2cVERSION%3dV4.0%22%29&rd=true

Deselecciono y luego vuelvo a seleccionar el " Habilitar ClickOnce configuración de seguridad " casilla de verificación. Ha estado libre de problemas desde hace unos días....

Para mí esto fue causado por tener un símbolo del sistema abierto en la carpeta de destino (C:\users\username\source\repos\project\project\bin\debug\app.publish).

No estoy seguro de por qué la DEPURACIÓN requiere acceso a la carpeta de publicación, pero cerrar la ventana de comandos me resolvió el problema.

Probé varias soluciones que usted proporcionó, pero de vez en cuando todavía recibo este error. Estoy seguro de que mi proceso no se está ejecutando, y cuando intento eliminar el archivo ejecutable con Internet Explorer se elimina de la lista de archivos, pero luego presiono F5 y listo, el archivo está de vuelta. No se ha suprimido en absoluto.

Pero si elimino el archivo a través del TotalCommander, el archivo exe se elimina y puedo construir el proyecto con éxito.

Estoy usando windows 7 x64 y total commander 7.56 a 32 bit.

Ninguna de las otras respuestas funcionó para mí, pero cerrar todas las pestañas abiertas en Visual Studio parece haber resuelto el problema.

Sé que esta es una pregunta muy antigua, pero recientemente experimenté el error "no se puede copiar de obj a bin" en VS 2012. Cada vez que intentaba reconstruir un determinado proyecto, recibía el mensaje. La única solución era hacer una limpieza antes de cada reconstrucción.

Después de mucho investigar, resulta que tenía una declaración de advertencia pragma incompleta en uno de mis archivos que no impidió que la compilación tuviera éxito, pero de alguna manera confundía a VS para mantener el archivo (s) bloquear.

En mi caso, tenía lo siguiente en la parte superior del archivo:

#pragma warning(

Eso es todo. Supongo que estaba tratando de hacer algo hace un tiempo y me distraje y nunca terminé el proceso, pero las advertencias VS sobre esa línea en particular se perdieron en la baraja. Finalmente noté la advertencia, eliminé la línea y reconstruí las obras cada vez desde entonces.

Primero haz las cosas simples.

Compruebe que parte de la solución no está bloqueada por un proceso en ejecución.

Por ejemplo, ejecuté "InstallUtil" en mi servicio Windows(que normalmente pruebo unitariamente desde una consola).

Esto bloqueó algunos de mis archivos DLL en la carpeta bin del proyecto de servicio de Windows. Cuando hice una reconstrucción obtuve la excepción en este número.

Detuve el servicio de Windows, reconstruido y tuvo éxito.

Compruebe el Administrador de tareas de Windows para su Solicitud, antes de realizar cualquiera de los pasos previos en este número.

Así que cuando oigas pasos, ¡piensa en caballos, no en cebras! (de amigo estudiante de medicina)

Cuando me enfrenté a un problema similar, lo único que parecía funcionar fue:

• Haga clic con el botón derecho en el proyecto, vaya a Configuración y asegúrese de que tanto las compilaciones de Depuración como de liberación tengan como objetivo la misma configuración, o tengan la configuración que la aplicación intenta cargar o guardar.
• Eliminar el C:\Users(Su cuenta de usuario)\AppData\Carpeta local (Su nombre de usuario).
• Asegurándome de que ningún archivo que tenía allí fuera considerado "Bloqueado". Hacer clic derecho en mi proyecto incluido archivos, me di cuenta de que un icono estaba realmente bloqueado y considerado malo porque se descargó de Internet. Tuve que hacer clic en el botón Desbloquear (por ejemplo, mira esto: http://devierkoeden.com/Images/Articles/Dynamicweb/CustomModules/Part1/BlockedFiles.png - "Este archivo vino de otro equipo y podría estar bloqueado para ayudar a proteger este equipo.").

Para los servicios de Windows que utilizan WCF, terminé el proceso de host WFC y funcionó. Odio cuando esto sucede, y a veces sucede al azar.

Mi solución no tiene nada que ver con versiones, procesos bloqueados, reinicio o eliminación de archivos.

El problema se debió en realidad a que la compilación falló y no dio el error correcto. El problema real era un defecto de diseño:

// Either this should be declared outside the function, or..
SomeObject a = new SomeObject(); 

Task.Factory.StartNew(() =>
{
   while (true)
   {
      a.waitForSomething();
   }
});

// ...this should not be called
a.doSomething(); 

Después de cambiar el alcance de "a" a fuera de la función, o no usar "a" después de Task.Factory.StartNew();, pude construir de nuevo.

Esto sucedió al usar la actualización 4 de VS2012 en Windows7x64 sp1.

Mensaje de error:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(3390,5): error MSB3030: No se pudo copiar el archivo "obj\x86\Debug\xxx.exe" porque no fue encontrado.

He encontrado que con VS2013 obtengo este error regularmente. Algo que parece funcionar razonablemente bien es realizar una solución de reconstrucción antes de intentar ejecutar la aplicación. Descubrí que realizar una LIMPIEZA a veces funciona, pero la solución de reconstrucción parece funcionar de manera más consistente.

Yo tenía el mismo problema. Dijo que no se podía copiar de bin \ debug a obj.....

Cuando compilo un proyecto web encontré que mi dll estaba todo en la carpeta bin y no en bin\debug. Durante la publicación vs estaba buscando archivos en bin \ debug. Así que abrí el archivo de proyecto web en el editor y busque instancias de bin \ debug y encontré que todas las dll se mencionaron como bin \ debug\mylibrary.DLL. Eliminé todo \debug de la ruta y publiqué de nuevo. Esta vez vs fue capaz de encontrar todo el dll en la carpeta bin y publicar éxito.

No tengo idea de cómo se cambió esta ruta en el archivo de proyecto web.

Pasé más de 5 horas depurando esto y finalmente encontré la solución por mi cuenta.

Esta es la respuesta correcta.

Esto me ayuda después de eliminar el indicador de solo lectura del directorio bin. http://www.thewindowsclub.com/error-0x80080015-windows-defender-activation-requires-display-name