vista - Visual Studio bloquea el archivo de salida en la compilación

visual studio code close tag

Question

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 compilaciones 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 compilació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 bloqueo ocurre después de la compilación, no después de la depuración (es decir, se inicia VS - compilación - compilació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 compilación impidió la descarga, pero la (primera) compilación se completa sin ningún otro mensaje que no sea "1 éxito, o error" /

Answer 1

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

Answer 2

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)

Answer 3

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

Answer 4

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 compilació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.

Answer 5

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

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

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

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

Answer 6

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.

Answer 7

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.

Answer 8

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 programa ya instalado.

Answer 9

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.

Answer 10

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 bloqueos:

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.

Answer 11

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.

Answer 12

También existe un problema conocido en 533411 en el que el uso de la actualización automática de números de compilación puede causar el problema de bloqueo. 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")]

Answer 13

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 compilar. La solución fue bastante fácil, solo tuve que cerrar cualquier Form / UserControl antes de construir la solución y funcionó.

Answer 14

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 compilació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"

Answer 15

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

Compile la utilidad en la respuesta aceptada y haga referencia a ella durante el paso de compilació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.

Answer 16

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-compilación

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

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 compilation 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%"