Visual Studio bloquea el archivo de salida en la comstackción

Tengo una solución WinForms simple en VS 2010. Cada vez que lo construyo, el archivo de salida (bin \ debug \ app.exe) termina bloqueado, y las comstackciones subsiguientes fallan con un mensaje como "The process cannot access the file 'bin\Debug\app.exe' because it is being used by another process." La única forma de construir el proyecto es reiniciar VS después de cada comstackción, lo cual es muy incómodo.

He encontrado esta vieja publicación de blog http://blogs.geekdojo.net/brian/archive/2006/02/17/VS2005FileLocking.aspx – parece que el problema es realmente viejo. ¿Alguien sabe lo que está sucediendo aquí, o al menos alguna solución?

Actualizar

En realidad, no ejecuto el archivo. El locking ocurre después de la comstackción, no después de la depuración (es decir, se inicia VS – comstackción – comstackción – falla!) Y traté de apagar el antivirus. No ayuda.

Actualización 2

Process Explorer muestra que devenv.exe ha cargado el archivo (en DLL, no en Handles). Parece que alguna falla durante la comstackción impidió la descarga, pero la (primera) comstackción se completa sin ningún otro mensaje que no sea “1 éxito, o error” /

Tuve el mismo problema, pero encontré una solución (gracias a Keyvan Nayyeri ):

Pero, ¿cómo resolver esto? Hay varias formas basadas en su tipo de proyecto, pero una solución simple que recomiendo a los desarrolladores de complementos de Visual Studio es agregar un código simple a los eventos de comstackción de su proyecto.

Puede agregar las siguientes líneas de código a la línea de comando de evento de preconstrucción de su proyecto.

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

No es un problema de virus. Es un error de Visual Studio 2010. Parece que el problema está relacionado con el uso de visual studio gui designer.

La solución aquí es mover el archivo de salida bloqueado a otro temporal en el evento de preconstrucción. Tiene sentido generar un nombre de archivo temporal al azar.

 del "$(TargetPath).locked.*" /q if exist "$(TargetPath)" move "$(TargetPath)" "$(TargetPath).locked.%random%" exit /B 0 

En caso de utilizar nombres de archivos temporales constantes, simplemente pospondrá los lockings:

Esa solución funciona exactamente una vez

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

También encontré una solución con 2 archivos temporales que funciona exactamente 2 veces.

El problema también se me ocurrió.

Mi situación era la siguiente: ejecutar Windows 7 (pero también podría suceder en Windows XP) y mientras trabajaba en un proyecto con WPF User Control podía construir todas las veces, hasta abrir el archivo XAML del control de usuario: desde allí, me ‘ Tengo una comstackción, y luego los archivos están bloqueados.

Además, me he dado cuenta de que estaba ejecutando Visual Studio (Devenv.exe) como administrador, comencé a ejecutar Visual Studio sin privilegios de administrador y el problema desapareció. .

Avísame si te ayudó también. Buena suerte.

He visto esto en un codicioso software de escaneo de virus, o si app.exe no se cierra correctamente. Asegúrate de que el proceso aún no se esté ejecutando.

¿Qué pasa con los escáneres de virus en su máquina? ¿Puedes ver algún proceso que tenga controladores en tu archivo (usa Process Explorer para averiguarlo)?

¿Tal vez hay “app.exe” visible en su lista de procesos, es decir, la última versión que depuró todavía se está ejecutando? Cuando desarrolla aplicaciones que tienen varios hilos, esto puede suceder si no los join todos.

Tuve el mismo problema y me enteré de que VS solo bloquea el exe cuando abrí un formulario o un UserControl en VS antes de comstackr. La solución fue bastante fácil, solo tuve que cerrar cualquier Form / UserControl antes de construir la solución y funcionó.

También existe un problema conocido en 533411 en el que el uso de la actualización automática de números de comstackción puede causar el problema de locking. Solución del informe de errores

La solución temporal sería deshabilitar la actualización de la versión de ensamblaje después de la reconstrucción. En el archivo AssemblyInfo.cs, elimine el comodín del atributo AssemblyVersion, por ejemplo:
reemplazar esto:
[assembly: AssemblyVersion (“1.4. *”)]
[assembly: AssemblyFileVersion (“1.4”)]
con este:
[assembly: AssemblyVersion (“1.4.0.0”)]
[assembly: AssemblyFileVersion (“1.4.0.0”)]

Tuve este problema y lo resolví con un código personalizado. Vea aquí: problemas de locking del archivo de comstackción de Visual Studio 2010

Compile la utilidad en la respuesta aceptada y haga referencia a ella durante el paso de comstackción como se describe para solucionar el problema. Todavía apago VS 2010 en el almuerzo para limpiar el trabajo de la mañana.

El motivo del código personalizado era que la solución recomendada a menudo solo funcionaba una vez y luego los archivos renombrados también se bloqueaban, lo que impedía el cambio de nombre. Aquí solo anexamos la información de tiempo de datos al archivo para que las versiones renombradas no puedan entrar en conflicto.

Basándome en la gran respuesta de Stormenet , coloqué un pequeño script que debería funcionar en todos los casos.

Aquí está el código para poner en el cuadro de texto del evento pre-comstackción

 $(SolutionDir)\BuildProcess\PreBuildEvents.bat "$(TargetPath)" "$(TargetFileName)" "$(TargetDir)" "$(TargetName)" 

Evento de construcción previa

Aquí está la secuencia de comandos para copiar en el archivo $(SolutionDir)\BuildProcess\PreBuildEvents.bat (por supuesto, puede modificar esta ruta):

 REM This script is invoked before compiling an assembly, and if the target file exist, it moves it to a temporary location REM The file-move works even if the existing assembly file is currently locked-by/in-use-in any process. REM This way we can be sure that the comstacktion won't end up claiming the assembly cannot be erased! echo PreBuildEvents echo $(TargetPath) is %1 echo $(TargetFileName) is %2 echo $(TargetDir) is %3 echo $(TargetName) is %4 set dir=C:\temp\LockedAssemblies if not exist %dir% (mkdir %dir%) REM delete all assemblies moved not really locked by a process del "%dir%\*" /q REM assembly file (.exe / .dll) - .pdb file - eventually .xml file (documentation) are concerned REM use %random% to let coexists several process that hold several versions of locked assemblies if exist "%1" move "%1" "%dir%\%2.locked.%random%" if exist "%3%4.pdb" move "%3%4.pdb" "%dir%\%4.pdb.locked%random%" if exist "%3%4.xml.locked" del "%dir%\%4.xml.locked%random%" REM Code with Macros REM if exist "$(TargetPath)" move "$(TargetPath)" "C:\temp\LockedAssemblies\$(TargetFileName).locked.%random%" REM if exist "$(TargetDir)$(TargetName).pdb" move "C:\temp\LockedAssemblies\$(TargetName).pdb" "$(TargetDir)$(TargetName).pdb.locked%random%" REM if exist "$(TargetDir)$(TargetName).xml.locked" del "C:\temp\LockedAssemblies\$(TargetName).xml.locked%random%" 

Lo único que funcionó para mí fue abandonar Visual Studio 2012, eliminar las carpetas BIN y OBJ para el proyecto que tenía problemas y abrir Visual Studio nuevamente.

Problema resuelto … hasta la próxima.

Si su $ (TargetPath) apunta a una DLL que usa COM asegúrese de tener un constructor predeterminado. No estoy seguro de por qué el constructor predeterminado no se deduce allí. Agregar el constructor predeterminado funcionó para mí en este escenario.

Cerrar el estudio visual, volver a abrir y volver a cargar la solución más reciente me soluciona el problema. (Visual Studio 2013 Ultimate)

Me encontré con lo mismo desarrollando aplicaciones xamarin en VS2017.

Resultó ser Windows Defender bloqueando el exe / dll con devenv.exe.

Puedes ir a Win Defender y agregar

 devenv.exe msbuild.exe 

a la lista de exclusión de procesos.

Esta es la solución que descubro

  1. Desmarque el proceso de alojamiento de Visual Studio en la configuración del proyecto como se muestra a continuación

enter image description here

  1. Mata al exe. será tu applicationname.vshost.exe desde taskmanager

enter image description here

  1. Ahora puedes reconstruir tu aplicación y ejecutarla.

Nota: puede volver a habilitar esta opción sin problemas.

Logré solucionar este problema desactivando el análisis en tiempo real de McAfee LiveSafe. Mi archivo .exe se cerraría como lo describe OP y no tendría forma de eliminar el archivo, lo que significaba que no podía construir la solución. Después de deshabilitar la función de McAfee, el problema desapareció.

Luego, por supuesto, procedí a desinstalar completamente McAfee, que solo se instaló porque mi PC es nueva y vino con el progtwig ya instalado.

Creé una nueva solución en blanco y agregué todos los archivos antiguos. Esto de alguna manera resolvió el problema.