2009-11-30 32 views
25

Usando 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 mediante el cierre de la aplicación o haga clic en el botón de parada de depuración, todos los intentos posteriores para depurar la aplicación fallar con:¿Por qué obtengo el error "el archivo es utilizado por otro proceso" cuando depuro dentro de Visual Studio?

de 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 utilizado por otro proceso .

Handle.exe de SysInternals muestra los identificadores abiertos, pero incluso si cierro los identificadores, el error no desaparece. Cualquier intento de eliminar el archivo de forma manual dará como resultado un mensaje de error de "Acceso denegado".

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

No estoy del todo seguro de cuándo comenzó esto, pero estoy bastante seguro de que es bastante reciente.

ACTUALIZACIÓN: Después fuerzo cerrar las asas de Application.dll, me sale el siguiente error de VS:

de error 1 No se puede copiar el archivo "obj \ Debug \ Application.dll" a "bin \ Debug \ Application.dll". La operación solicitada no puede ser realizada en un archivo con una sección mapeada por el usuario abierta.

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

ACTUALIZACIÓN 2: Parece que este problema se produce cuando tengo un formulario abierto en la vista de diseño cuando intento depurar. Voy a hacer algo más de solución de problemas y luego publicaré mis resultados.

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

+1

¿Ha intentado matar el proceso Applocation.vshost.exe en lugar de reiniciar Visual Studio? – Nestor

+0

Sí, NO PUEDE ser asesinado. El proceso no morirá hasta que cierre VS. –

+1

"Parece que este problema ocurre cuando tengo un formulario abierto en la vista Diseño" Esto lo hizo por mí. Estaba obteniendo tu error. Cuando cerré todos los archivos XAML abiertos, el error desapareció. – user2023861

Respuesta

11

Para ser honesto, parece un error en VS2010. Por algún motivo, no cierra los identificadores abiertos cuando se detiene el depurador. Al matar el proceso de VS se cierran automáticamente esos identificadores, lo que te permite acceder al archivo nuevamente. Como alternativa, puede mirar unlocker, es gratis y funciona excepcionalmente bien. Sé que no es una gran respuesta, pero debería ser más rápido que reiniciar VS. También podría considerar enviar un informe de error ...

Edit: Unlocker no funciona en el sistema operativo de 64 bits, LockHunter sí lo hace.

+29

¿Espera, Chris Thompson respondiendo a Chris Thompson? LOL. –

+1

@Andy Lo sé, hice una doble toma ;-) –

+1

Es un error confirmado en VS2010 que se supone que debe abordarse en SP1. –

2

He visto el servicio de indización de Windows causar esto. Deshabilitarlo ayudó. Los escáneres de virus también pueden tener la culpa. Las llamadas a Mutliple Application.Close() supuestamente pueden causar esto también.

EDITAR: Por supuesto, dado que siempre funciona la primera vez, supongo que es poco probable.

8

Así es como he resuelto este problema

* abro las propiedades del proyecto, * seleccione la pestaña de construcción, * Borrar la ruta de salida, * y buid (esto va a crear el archivo DLL en la carpeta raíz) * regrese a la ruta de salida y seleccione examinar (busque el directorio bin para depurar/liberar) y ¡listo!

+2

Voila! Trabajó para mí también, gracias! – Dan

+0

¡Guau! ¡tu eres el hombre! – Maciej

+0

Esto ha resurgido para mí en VS2015 y esto resolvió mi problema. – GibralterTop

0

Me encontré con el mismo problema y en mi caso tuve el archivo en cuestión abierto en Visual Studio. Cerrar todos los archivos ayudó.

1

Tenía el mismo problema. Las siguientes cosas ayudaron

  1. Cierre todos los archivos de diseño durante la depuración
  2. usando desbloqueador

También mi aplicación abre un puerto. Al depurar, se lanzó una excepción y el programa se cerró. Mientras terminaba el programa, cerré el puerto. Eso ayudó también.

Pero definitivamente, error con VS2010.

-1

Esto es muy frustrante. Realmente pensando en pasar a VS2013 y VS2010 está cargado de problemas y a MS parece no importarle. Algunos de nosotros realmente no tenemos el lujo de pagar por un nuevo software, pero parece que tendré que morder la bala. He tenido este problema constantemente durante más de dos semanas. He borrado cualquier configuración para VS2010. Puedo tener el uso devenv/Resetsettings, ejecutar VS2010 como administrador y aún así tener este problema. Cuando MS dice que no pueden reproducir esto en el laboratorio es porque tienen un sistema prístino o simplemente están colocando pantallas de humo. Literalmente estoy sacando mi cabello con esto.

+0

¡Siento tu dolor! –

0

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 en él. He añadido la referencia de estas bibliotecas a mi proyecto principal y por error

added reference to same project to itself. So when 
    I removed self reference, it worked. 
4

Según Error: Cannot access file bin/Debug/… because it is being used by another process answer by TarmoPikaro, a veces Visual Studio crea múltiples procesos de fantasmas MSBuild.exe, que persisten después de la construcción. Estos procesos fantasmas parecen estar causando bloqueos de archivos.

Solución 1 - Matar

asesinato de MSBuild.exe fantasma de MSBuild.exe es una solución de una sola vez, tiene que ser hecho por base de acumulación.

Puede matar a los procesos de la siguiente manera mrtumnus:

taskkill/f/im MSBuild.exe

Solución 2 - Desactivar paralelo se basa en Visual Studio

Puede desactivar la acumulación paralela de una vez por Todo:

Herramientas> Opciones> Proyectos y soluciones> Compilar y ejecutar> "Números máximos de compilaciones de proyectos paralelos": de forma predeterminada tiene el valor de 8, cambie a 1.

Por supuesto, las construcciones son ahora un poco más lentas, pero el kilometraje puede variar según su caso de uso.

esto está relacionado con Error: Cannot access file bin/Debug/... because it is being used by another process

Cuestiones relacionadas