La compilación de Visual Studio falla: no se puede copiar el archivo exe de obj \ debug a bin \ debug

193

Actualización: un proyecto de muestra que reproduce este error se puede encontrar aquí en Microsoft Connect . También probé y verifiqué que la solución dada en la respuesta aceptada a continuación funciona en ese proyecto de muestra. Si esta solución no funciona para usted, es probable que tenga un problema diferente (que pertenece a una pregunta separada).


Esta es una pregunta que se hizo antes, tanto aquí en Stack Overflow como en otros lugares, pero ninguna de las sugerencias que he encontrado hasta ahora me ha ayudado, así que solo tengo que intentar hacer una nueva pregunta.

Escenario: Tengo una aplicación simple de Windows Forms (C #, .NET 4.0, Visual Studio 2010). Tiene un par de formas base de las cuales la mayoría de las otras formas heredan, usa Entity Framework (y clases POCO) para acceder a la base de datos. Nada sofisticado, no multihilo ni nada.

Problema: todo estuvo bien por un tiempo. Luego, de la nada, Visual Studio no se pudo compilar cuando estaba a punto de iniciar la aplicación. Recibí la advertencia "No se puede eliminar el archivo '... bin \ Debug \ [ProjectName] .exe'. El acceso a la ruta '... bin \ Debug \ [ProjectName] .exe' está denegado". y el error "No se puede copiar el archivo 'obj \ x86 \ Debug \ [ProjectName] .exe' a 'bin \ Debug \ [ProjectName] .exe'. El proceso no puede acceder al archivo 'bin \ Debug \ [ProjectName] .exe 'porque está siendo utilizado por otro proceso ". (Recibo tanto la advertencia como el error al ejecutar Rebuild, pero solo el error al ejecutar Build, ¿no cree que sea relevante?)

Entiendo perfectamente lo que dice el mensaje de advertencia y error: Visual Studio obviamente está tratando de sobrescribir el archivo exe mientras que al mismo tiempo tiene un bloqueo por alguna razón. Sin embargo, esto no me ayuda a encontrar una solución al problema ... Lo único que he encontrado que funciona es cerrar Visual Studio y volver a iniciarlo. La creación y el inicio funcionan, hasta que realice un cambio en algunos de los formularios, luego tengo el mismo problema nuevamente y tengo que reiniciar ... ¡Muy frustrante!

Como mencioné anteriormente, este parece ser un problema conocido, por lo que hay muchas soluciones sugeridas. Solo enumeraré lo que ya he probado aquí, para que la gente sepa qué omitir:

  • Crear una nueva solución limpia y simplemente copiar los archivos de la solución anterior.
  • Agregar lo siguiente a lo siguiente al evento de precompilación del proyecto:

    if exist "$(TargetPath).locked" del "$(TargetPath).locked"
       if not exist "$(TargetPath).locked" if exist "$(TargetPath)" move "$(TargetPath)" "$(TargetPath).locked"
  • Agregar lo siguiente a las propiedades del proyecto (archivo .csproj):

    <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>

Sin embargo, ninguno de ellos funcionó para mí, por lo que probablemente pueda ver por qué estoy comenzando a sentirme un poco frustrado. No sé dónde buscar, ¡así que espero que alguien tenga algo que darme! ¿Es esto un error en VS, y si es así, hay un parche? ¿O he hecho algo mal, tengo una referencia circular o similar, y si es así, cómo podría averiguarlo?

Cualquier sugerencia es altamente apreciada :)

Actualización: como se menciona en el comentario a continuación, también he comprobado usando Process Explorer que en realidad es Visual Studio el que está bloqueando el archivo.

Julian
fuente
44
¿Ha verificado si su aplicación se cierra correctamente? ¿El administrador de tareas le muestra [ProjectName] .exe en la lista de procesos?
miensol
2
He tenido esto antes y simplemente cambié el nombre del archivo a .old, etc. y volví a ejecutar la compilación. No sé exactamente una solución, pero funcionó para mí.
codingbadger
@miensol: Sí, parece cerrarse correctamente. Obtengo "El programa '[1848] [ProjectName] .vshost.exe: Managed (v4.0.30319)' ha salido con el código 0 (0x0)". @Barry: cambiar el nombre del archivo exe en bin \ Debug funciona, pero como dijiste, no es realmente una solución y será bastante molesto tener que hacerlo todo el tiempo. Aunque es un poco mejor que reiniciar Visual Studio ...
Julian
2
@Naliluj: Me encontré con este artículo de un foro de Microsoft que explica que puede estar relacionado con archivos de recursos. Si está utilizando archivos resx, esto podría dar una pista.
Patrick
1
Para la posteridad, tuve este problema y se resolvió agregando el elemento <GenerateResourceNeverLockTypeAssemblies> true </GenerateResourceNeverLockTypeAssemblies> a mi archivo csproj.
ThisIsTheDave

Respuestas:

117

Esto va a sonar estúpido, pero probé todas estas soluciones, ejecutando VS2010 en Windows 7. Ninguno de ellos funcionó, excepto el cambio de nombre y la construcción, que fue MUY tedioso por decir lo menos. Finalmente, rastreé al culpable y me cuesta creerlo. Pero estaba usando el siguiente código en AssemblyInfo.cs ...

[assembly: AssemblyVersion("2.0.*")]

Esto es bastante común, pero por alguna razón, cambiar la versión a 2.0.0.0 hizo que las cosas volvieran a funcionar. No sé si es algo específico de Windows 7 (solo lo he estado usando durante 3-4 semanas), o si es aleatorio, o qué, pero me lo arregló. Supongo que VS estaba controlando cada archivo que generaba, por lo que sabría cómo incrementar las cosas. Realmente no estoy seguro y nunca he visto que esto suceda antes. Pero si alguien más también se está sacando el pelo, pruébalo.

drharris
fuente
12
Esa es una idea loca, te lo daré;) Lo que es aún más loco, ¡es que realmente parece funcionar! He probado esto varias veces y puedo confirmar que cuando uso una versión de ensamblaje como "2.0. *" Aparece el error, pero cuando uso "2.0.0" ¡funciona como un encanto! Insto a más personas a que prueben esto, y si lo encuentra funcionando, vote esta respuesta, ¡porque esto es algo que debe saberse! Espero que Microsoft recoja esto ... Gracias drharris :)
Julian
2
esto no funcionó para mí, cuando reinicié VS no recibí ningún error por algún tiempo. Cada vez que recibo este error tengo que reiniciar VS 2010
Sharique
66
digo ... esto no funcionó para mí. Mi configuración siempre ha sido: [ensamblado: AssemblyVersion ("1.0.0.0")] [ensamblado: AssemblyFileVersion ("1.0.0.0")]
tbone
44
Si actualmente tiene [assembly: AssemblyVersion ("1.0.0.0")], reemplácelo con [assembly: AssemblyVersion ("2.0.0.0")] (es decir, '2' en lugar de '1'). Funcionó para mi. Aunque no lo he verificado, es posible que simplemente cambiando la versión a otra que no sea la que tienes ahora puede solucionar este problema.
Federico el tonto
1
Funciona para dll también! VS dice que no puede copiar el dll y después de cambiar AMBOS [ensamblaje: Ensamblaje de la Asamblea] y [ensamblaje: Ensamblaje del Ensamblaje ()] de 1.0. * A 2.0.0.0, funcionó.
AZ.
14

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

Como lo sugirió Barry en un comentario a la publicación original, renombrar manualmente '... bin \ Debug [ProjectName] .exe' a otra cosa (por ejemplo, '[ProjectName] 1.exe' ) es una solución alternativa (I ' Sin embargo, no se me permite eliminar el archivo yo mismo, y debo decir que me parece un poco extraño, ya que uno creería que el mismo bloqueo que evita la eliminación también evitaría cambiar el 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 de forma semialeatoria. Suele suceder después de haber realizado 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 el código no visual relacionado (pero a veces sucede ...). De hecho, es frustrante, pero al menos tengo un truco que funciona para mí. Esperemos que mi próximo proyecto no también enfrente este problema ...

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

Julian
fuente
He votado esto ya que esto es lo que he hecho en el pasado. Estoy de acuerdo, es una solución sucia pero funciona. VS ha tenido este problema durante algunas iteraciones. Estoy cargando mi proyecto desde un directorio de red también. Se ha confiado plenamente, pero no importa. No importa si es un mapeo de unidades o un UNC tampoco. Sí, MS realmente necesita arreglar esto. Tienen un error cerrado que dice que no se puede reproducir. ¡Cojo!
Josh Robinson
14

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

Pedro
fuente
2
Esto funcionó para mí también. No estoy seguro de entender por qué, ya que el explorador de procesos mostró que devenv.exe sostenía el asa de bloqueo. Sin embargo, desactivar la indexación solucionó el problema.
Fopedush
1
@Fopedush Encontré este problema con la misma solución, aunque no vi esta pregunta en ese momento. Esta respuesta tiene alguna explicación de por qué ayuda.
Darren Hale
1
Este lo hizo por mí.
Martin Capodici
12

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

Sergey
fuente
1
Encontré este informe de error reciente sobre este problema exacto: connect.microsoft.com/VisualStudio/feedback/details/558848/… Ese informe de error proporcionó un proyecto de muestra que pudo reproducir el error. La solución sugerida por drharris también funcionó allí (consulte la solución publicada en el enlace anterior para obtener una solución paso a paso para el proyecto de muestra).
Julian
Esta es la única solución que también funcionó para mí. Gracias @Nailuj!
Extremo
Esto es seguro más fácil que reiniciar VS.
Elvedin Hamzagic
1
"Página no encontrada" para el problema de conexión, ¿simplemente lo eliminaron por vergüenza = S ¿Hubo alguna vez una solución / solución publicada para esto?
Coops
9

Cuando me encuentro con este problema, tiene que ver con el hecho de que el proyecto que estoy tratando de construir está configurado como el proyecto de inicio en la solución que bloquea el .exe en la carpeta obj (también aparece en su administrador de tareas) haga clic derecho en otro proyecto en su solución y elija establecer proyecto de inicio. Esto liberará el bloqueo, lo eliminará del administrador de tareas y debería permitirle construir.

Adrian Booth
fuente
1
Esto funciona todo el tiempo para mí. Parece que tiene que ver con el proceso vshost que se genera y se inicia para los servicios
jaywayco
8

Intenté todas las otras sugerencias en las respuestas aquí, ninguna de las cuales funcionó. Finalmente, utilicé Process Monitor para descubrir que mi .exe que VS2010 no podía construir estaba bloqueado por el proceso del Sistema (PID = 4). Buscar SO para situaciones que involucran esto arrojó esta respuesta.

Resumido: si tiene el servicio Application Experience deshabilitado (como lo hice), vuelva a habilitarlo e inícielo. Dos años de agravación terminaron.

Gurú de ocho bits
fuente
+1 Intenté previamente todo lo demás (1. administrador de tareas, 2. explorador de procesos, es decir, manejar de cerca lo que Windows no me permitía hacer, 3. Desactivar antivirus, 4. excluir APP_DATA / Local / Microsoft / Visual Studio del servicio de indexación de Windows. ) pero este consejo es: el servicio "Application Experience" es el único que me salvó golpeándome la cabeza contra la pared. Lo habilité y el problema desapareció. Lo curioso es que, después de volver a desactivarlo, todo seguía bien. No he tenido más problemas. Pero definitivamente esto es lo único que lo resolvió para mí.
Tomás
¡Trabaja para mí también! Lo único que funciona también es eliminar la carpeta bin antes de ejecutar la aplicación, pero debes eliminarla siempre antes de ejecutarla, lo cual es muy molesto.
E_Blue
6

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

Quinxy von Besiex
fuente
Tengo instalado Avast y esta mañana recibí un error aleatorio de MVC que decía que mi dll tenía un virus. Después del error, ya no podía construir mi proyecto MVC. Agregué una excepción al Avast File System Shield y todo vuelve a funcionar.
Dusty
5

Deshabilitar "Habilitar el proceso de alojamiento de Visual Studio" Configuración de depuración del proyecto

Software BCS
fuente
4

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

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

Hans Olsson
fuente
Estoy de acuerdo, no es necesariamente VS lo que está bloqueando el archivo. Los verificadores de virus pueden ser culpables de esto. Intente apagar su antivirus para ver si eso ayuda.
Polyfun
Lo siento, olvidé mencionar que ya lo hice. Y dice que es Visual Studio (devenv.exe) que tiene un bloqueo en el archivo ([ProjectName] .vshost.exe). Eso tampoco me ayuda mucho.
Julian
@ShellShock: deshabilitar mi antivirus (Avast) tampoco ayuda.
Julian
Para mí, usando Sysinternals ProcessExplorer, puedo ver un identificador de ese archivo, pero cuando hago clic en él, no se muestra ninguna aplicación que lo sostenga, y cuando trato de cerrar el identificador, aparece un "Error al abrir el proceso: el identificador inválido." error en ProcessExplorer. Sin embargo, la cerradura aún persiste.
tbone
4

Al usar 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 aquellos interesados, he adjuntado un seguimiento de identificador para el identificador infractor:

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
danielm
fuente
si ve en la parte superior de la pregunta, hay un enlace a Microsoft Connect con un informe de error y un proyecto de muestra que reproduce el error: connect.microsoft.com/VisualStudio/feedback/details/558848/…
Julian
Deshabilitar el proceso de alojamiento funcionó para mí. Sigue funcionando después de volver a habilitarlo también. Pasé 4 horas tratando de solucionar este problema probando cientos de soluciones. Este es el único que incluso remotamente parecía funcionar.
Drew Chapin el
4

SI SU PROBLEMA NO SE RESUELVE AÚN:

El error de Visual Studio es:

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

Por lo tanto, vaya al administrador de tareas de Windows (Ctrl + Shift + Esc), busque el nombre de su aplicación y fuerce su cierre por Endprocces.

AmirHossein Rezaei
fuente
3

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 diseñador de interfaz de usuario XAML estaba usando el archivo.

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


y otra posible causa:

He notado otra posible causa de este problema. Después de hacer una 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 al estudio visual a pensar que podría construir algunos proyectos al mismo tiempo, creando así los bloqueos de archivos.

EDITAR: Me ha sucedido esto en algunas ocasiones, incluso recientemente, con VS2012 y lo soluciona una vez que establezco el orden de compilación en las dependencias correctas, elimino los procesos de msbuild que VS dejó en ejecución y luego reinicié VS. Elimino los procesos de msbuild solo para estar seguro, pero cerrar VS también debería eliminarlos.

Lo que generalmente hago para causar esto es refactorizar un proyecto de modo que se base en otro proyecto dentro de la solución que no hacía referencia en la última compilación. Esto a veces parece confundir a VS y no actualiza el orden de compilación.

Para verificar el orden de compilación: haga clic con el botón derecho en la Solución en el Explorador de soluciones y seleccione "Orden de compilación del proyecto ..." y verifique que las dependencias se anoten correctamente para cada proyecto.

Kevin Shanahan
fuente
Recientemente experimentamos esto en un proyecto WinPhone 8. Inexplicablemente, la causa estaba usando el tipo Tuple. Al eliminar el código que usaba una Tupla, el problema desapareció. Agregue el código de nuevo el problema devuelto.
Seamus
Tuve el mismo problema con VS2012, cerrar VS no hizo el truco: tengo que matar todas las tareas de msbuild.exe de forma manual
mizzle
Estoy usando VS 2013 y pude matar el proceso "XDesProc.exe * 32" (Diseñador de interfaz de usuario XAML de Microsoft Visual Studio) en el administrador de tareas antes de cada compilación y eso funcionó. No es necesario reiniciar VS porque el diseñador de interfaz de usuario XAML parece recargarse cada vez que abre un archivo * .xaml en la vista de diseño.
Tim Sexton
3

Reiniciar IIS: podría ser un proceso adjunto al depurador

Alan
fuente
3

Desactiva el antivirus y prueba. También estaba enfrentando ese problema ... pero en mi caso el antivirus estaba bloqueando mi aplicación cuando desactivé el antivirus, se resolvió.

Hassan_Jaffrani
fuente
3

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 en la versión.

Amanecer Utsav
fuente
1

Haz las cosas simples primero.

Verifique que parte de su solución no esté bloqueada por un proceso en ejecución.

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

Esto bloqueó algunos de mis dlls en la carpeta bin del proyecto de servicio de Windows. Cuando hice una reconstrucción, obtuve la excepción en este problema.

Detuve el servicio de Windows, reconstruí y tuvo éxito.

Verifique el Administrador de tareas de Windows para su aplicación, antes de realizar cualquiera de los pasos avanzados en este problema.

Entonces, cuando escuches pasos, ¡piensa en caballos y no en cebras! (de un amigo estudiante de medicina)

GregJF
fuente
1

Tuve el mismo problema Decía que no se podía copiar de bin \ debug a obj .....

Cuando construí un proyecto web, encontré que mi dll estaba 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 busqué instancias de bin \ debug y encontré que todos los dll se mencionaron como bin \ debug \ mylibrary.dll. Eliminé todo \ debug de la ruta y publiqué nuevamente. Esta vez vs pudo encontrar todo el dll en la carpeta bin y publicar con é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 .

nccsbim071
fuente
1

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

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

Greg
fuente
1

Esto es causado comúnmente por Avast.

Por lo general, puedo ejecutar mis proyectos en Release, pero cuando se ejecuta en depuración falla con bastante frecuencia.

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

James Pusateri
fuente
1

Renombrar el archivo .exe y .pub funcionó para mí, pero realmente tedioso. También me enfrento al problema de que no pude 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.NETFRAMVERSIÓN% % 3dV4.0% 22% 29 & rd = verdadero

Desactivo la selección y luego vuelvo a seleccionar la casilla de verificación "Habilitar configuración de seguridad de ClickOnce". Ha estado libre de problemas durante algunos días ...

Yee
fuente
1

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.

Bassie
fuente
1

En caso de que alguien se encuentre con esto mientras intenta depurar una Prueba unitaria o Ejecutar una prueba unitaria, tuve que eliminar los siguientes dos procesos para que libere el archivo:

procesos para matar.

Haggis777
fuente
0

Intenté varias soluciones que proporcionó, pero ocasionalmente todavía recibo este error. Estoy seguro de que mi proceso no se está ejecutando, y cuando trato de eliminar el archivo ejecutable con Internet Explorer, lo elimino de la lista de archivos, pero luego presiono F5 y listo, el archivo está de vuelta. No se ha eliminado en absoluto.

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

Estoy usando Windows 7 x64 y Total Commander 7.56a 32 bit.

Gico
fuente
0

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

Ian Mercer
fuente
0

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 intenté reconstruir un determinado proyecto, recibí el mensaje. La única solución era hacer una limpieza antes de cada reconstrucción.

Después de mucho investigar, resultó que tenía una declaración de advertencia de pragma incompleta en uno de mis archivos que no impidió que la compilación tuviera éxito, pero que de alguna manera confundió a VS al mantener los archivos bloqueados.

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

#pragma warning(

Eso es. Supongo que estaba intentando hacer algo hace un tiempo y me distraje y nunca terminé el proceso, pero las advertencias de VS sobre esa línea en particular se perdieron en la confusión. Finalmente, noté la advertencia, eliminé la línea y la reconstrucción funciona cada vez desde entonces.

Chris
fuente
0

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

  • Haga clic con el botón derecho en el proyecto, vaya a Configuración y asegúrese de que las compilaciones Debug y Release se dirijan a la misma configuración, o tengan la configuración allí que la aplicación intenta cargar o guardar.
  • Eliminar la carpeta C: \ Users (YourUserAccount) \ AppData \ Local (YourAppName).
  • Asegurándome de que ningún archivo que tuviera allí se considerara "Bloqueado". Al hacer clic con el botón derecho en los archivos incluidos de mi proyecto, me di cuenta de que un ícono en realidad estaba bloqueado y se consideraba malo porque se había descargado 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 otra computadora y podría estar bloqueado para ayudar proteger esta computadora ").
Alexandru
fuente
0

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

ShaunnyBwoy
fuente
0

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 la falla de la compilación y a no dar 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" fuera de la función, o no usar "a" después Task.Factory.StartNew();, pude construir de nuevo.

Esto sucedió al usar VS2012 Update 4 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 se encontró .

T.Coutlakis
fuente
0

He encontrado con VS2013 me sale 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.

mattpm
fuente