visual-studio - sirve - visual studio linux

¿Por qué obtengo errores de "otro archivo de proceso usado" cuando depuro en Visual Studio? (7)

Así es como resolví este problema.

* Abro las propiedades del proyecto, * selecciono la pestaña de compilación, * Borra la ruta de salida, * y buid (esto creará la dll en la carpeta raíz) * regresa a la ruta de salida y selecciona Examinar (navega hasta el directorio bin para ya sea debug / release) y voila!

Al usar Visual Studio 2010 beta, cuando ejecuto mi aplicación dentro del IDE para la depuración, funciona perfectamente la primera vez. Sin embargo, después de cerrar la sesión de depuración, ya sea cerrando la aplicación o haciendo clic en el botón para detener la depuración, todos los intentos posteriores de depuración de la aplicación fallarán con:

Error 1 No se puede copiar el archivo "obj / Debug / Application.dll" a "bin / Debug / Application.dll". El proceso no puede acceder al archivo ''bin / Debug / Application.dll'' porque está siendo usado por otro proceso.

Handle.exe de SysInternals muestra los manejadores abiertos, pero incluso si cierro los manejadores, el error no desaparece. Cualquier intento de eliminar el archivo manualmente genera un mensaje de error "Acceso denegado".

Para solucionar esto, tengo que reiniciar completamente Visual Studio, después de lo cual la sesión de depuración funcionará una vez y se detendrá nuevamente.

No estoy completamente seguro de cuándo empezó a suceder esto, pero estoy bastante seguro de que es bastante reciente.

ACTUALIZACIÓN : Después de forzar el cierre de los manejadores en Application.dll, recibo el siguiente error de VS:

Error 1 No se puede copiar el archivo "obj / Debug / Application.dll" a "bin / Debug / Application.dll". La operación solicitada no se puede realizar en un archivo con una sección asignada por el usuario abierta.

¿Qué diablos es una "sección asignada por el usuario"?

ACTUALIZACIÓN 2 : Parece que este problema ocurre cuando tengo un Formulario abierto en la vista Diseño cuando intento depurar. Voy a hacer un poco más de resolución de problemas y luego publicaré mis resultados.

ACTUALIZACIÓN 3 : Creo que lo he reducido a un formulario utilizando un UserControl.

Encontré el mismo problema y, en mi caso, tenía el archivo en cuestión abierto en Visual Studio. Cerrar todos los archivos ayudó.

He visto que el servicio de indexación de Windows causa esto. Deshabilitarlo ayudó. Los escáneres de virus también pueden ser culpables. Las aplicaciones Mutliple.Close () supuestamente pueden causar esto, también.

Por supuesto, ya que siempre funciona la primera vez, supongo que esto es poco probable.

Me enfrenté al mismo error y estuve atrapado en él durante muchos días. Finalmente resolvió el problema. Estaba trabajando en un proyecto que tenía muchas bibliotecas de clase agregadas. Agregué la referencia de estas bibliotecas a mi proyecto principal y agregué erróneamente la referencia al mismo proyecto a sí mismo. Así que cuando quité la auto-referencia, funcionó.

Para ser honesto contigo, suena como un error en VS2010. Por alguna razón, no está cerrando los manejadores abiertos cuando el depurador se detiene. Al matar el proceso de VS, se cierran automáticamente esos manejadores, lo que le permite acceder al archivo nuevamente. Como una alternativa, puede buscar en unlocker , es gratis y funciona excepcionalmente bien. Sé que no es una buena respuesta, pero debería ser más rápido que reiniciar VS. También puedes considerar enviar un informe de error ...

Unlocker no funciona en sistemas operativos de 64 bits, aunque LockHunter sí LockHunter hace.

Según error: No se puede acceder al archivo bin / Debug /… porque TarmoPikaro lo está utilizando en otra respuesta de proceso , a veces Visual Studio crea varios procesos fantasmas msbuild.exe, que persisten después de la compilación. Estos procesos fantasmas parecen estar causando bloqueos de archivos.

Solución 1 - Matar fantasmas MSBuild.exe''s

Matar msbuild.exe es una solución de una sola vez, se debe hacer por compilación.

Puede matar los procesos de la siguiente manera mrtumnus :

taskkill / f / im MSBuild.exe

Solución 2 - Deshabilitar compilaciones paralelas en Visual Studio

Puede deshabilitar la construcción en paralelo de una vez por todas:

Herramientas> Opciones> Proyectos y soluciones> Generar y ejecutar> "número máximo de compilaciones de proyectos en paralelo": por defecto tiene un valor de 8, cámbielo a 1.

Por supuesto, las compilaciones son un poco más lentas ahora, pero el kilometraje puede variar dependiendo de su caso de uso.

Esto está relacionado con Error: No se puede acceder al archivo bin / Debug / ... porque está siendo usado por otro proceso

Tenía el mismo problema. Las siguientes cosas ayudaron

Cerrar todos los archivos de diseño mientras se depura.
usando el desbloqueador

También mi aplicación abre un puerto. Mientras que la depuración se lanzó una excepción y el programa se cerró. Al finalizar el programa cerré el puerto. Eso también ayudó.

Pero definitivamente, bug con el VS2010.