185 votos

La construcción de Visual Studio falla: no se puede copiar el archivo exe del objeto \debug a la papelera \debug

Actualizar: Se puede encontrar un proyecto de muestra que reproduce este bicho aquí en Microsoft Connect . También he probado y verificado que la solución dada en la respuesta aceptada a continuación trabaja 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 ha hecho 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 sólo tengo que intentar hacer una nueva pregunta.

Escenario: Tengo una simple aplicación de Windows Forms (C#, .NET 4.0, Visual Studio 2010). Tiene un par de formularios base que la mayoría de los otros formularios heredan, utiliza Entity Framework (y clases POCO) para el acceso a la base de datos. No hay nada de fantasía, ni multihilo ni nada.

Problema: Todo estuvo bien por un tiempo. Luego, de repente, Visual Studio no se construyó cuando estaba a punto de lanzar la aplicación. Recibí la advertencia "No se puede borrar el archivo '...bin \Debug\ [Nombre del proyecto].exe'. Acceso a la ruta '...bin \Debug\ [Nombre del proyecto].exe' es negado". y el error "Incapaz de copiar el archivo 'obj \x86\Debug\ [Nombre del proyecto].exe' a 'bin \Debug\ [Nombre del proyecto].exe'. El proceso no puede acceder al archivo 'bin \Debug\ [Nombre del proyecto].exe' porque está siendo usado por otro proceso". (Recibo tanto la advertencia como el error al ejecutar Rebuild, pero sólo el error al ejecutar Build - ¿no crees que eso es relevante?)

Entiendo perfectamente lo que dice el mensaje de advertencia y error: Visual Studio está obviamente 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 apagar Visual Studio y volver a encenderlo. Construir y poner en marcha entonces funciona, hasta que hago un cambio en algunas de las formas, entonces tengo el mismo problema de nuevo y tengo que reiniciar... ¡Bastante frustrante!

Como mencioné anteriormente, este parece ser un problema conocido, por lo que hay muchas soluciones sugeridas. Sólo voy a enumerar lo que ya he intentado aquí, para que la gente sepa qué saltarse:

  • Creando una nueva solución limpia y copiando los archivos de la antigua solución.

  • Añadiendo lo siguiente al evento previo a la construcción del proyecto:

    si existe "$(TargetPath).locked" del "$(TargetPath).locked"
      si no existe "$(TargetPath).locked" si existe "$(TargetPath)" mover "$(TargetPath)" "$(TargetPath).locked"

  • Añadiendo lo siguiente a las propiedades del proyecto (archivo .csproj):

    <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>

Sin embargo, ninguno de ellos funcionó para mí, así que probablemente puedes ver por qué estoy empezando a frustrarme un poco. No sé dónde más 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 malo, tengo una referencia circular o similar, y si es así, cómo podría averiguarlo?

Cualquier sugerencia es muy apreciada :)

Actualizar: Como se menciona en el siguiente comentario, también he comprobado con el Explorador de Procesos que realmente es Visual Studio que está bloqueando el archivo.

114voto

drharris Puntos 6747

Esto va a sonar estúpido, pero probé todas estas soluciones, ejecutando VS2010 en Windows 7. Ninguna de ellas funcionó, excepto la de renombrar y construir, que fue MUY tedioso, por decir algo. Finalmente, encontré al culpable, y me resulta difícil de creer. 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 funcionaran de nuevo. No sé si es algo específico de Windows 7 (sólo lo he estado usando durante 3-4 semanas), o si es aleatorio, o qué, pero lo arregló para mí. Supongo que VS mantenía un control sobre cada archivo que generaba, para saber cómo incrementar las cosas? No estoy seguro y nunca he visto que esto ocurra antes. Pero si alguien más por ahí también se está tirando de los pelos, inténtalo.

14voto

Pedro Puntos 1656

Encontré una solución simple, sólo deshabilitar los servicios de indexación de Windows para la carpeta y subcarpetas del proyecto

13voto

Nailuj Puntos 7283

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

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

En caso de que alguien se pregunte, también podría añadir que sólo veo este problema de forma semi-aleatoria. Suele ocurrir después de que he hecho algunos cambios en el modo de diseño de un formulario (pero no siempre). Normalmente no ocurre si sólo cambio el código de lógica de negocio o el código no relacionado con lo visual (pero a veces ocurre...). Es frustrante, pero al menos tengo un hack que funciona para mí, esperemos que mi próximo proyecto no se enfrente a este problema también...

@Barry: si quieres que se te reconozca tu comentario, no dudes en publicarlo como respuesta y me aseguraré de aceptarlo :)

12voto

Sergey Puntos 101

Tengo el mismo problema (MSB3021) con el proyecto WPF en VS2008 (en Windows 7 x32). El problema aparece si trato de 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 desbloquea por sí mismo y puedo volver a ejecutar la aplicación. Pero una pausa tan larga me enfurece. La única cosa que realmente me ayudó fue ejecutar VS como Administrador.

6voto

Quinxy von Besiex Puntos 352

También tuve un problema muy similar a este y encontré que la razón en mi caso era que había hecho la papelera \debug disponible como carpeta compartida en VMware, y ya sea VMware, Explorer en el invitado de VM, o incluso un programa antivirus en el invitado (aunque no creo que tuviera uno instalado) tenía un mango para los archivos.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X