visual studio 2010 - temas - Depuración de VisualStudio2010: el proceso no puede acceder al archivo... porque está siendo utilizado por otro proceso
temas para visual studio code (30)
No puedo depurar una aplicación WinForms C # con la versión publicada de Visual Studio 2010 Prof.
Aparece el siguiente mensaje de error después de la segunda ejecución de depuración.
Error 9 No se puede copiar el archivo "obj / x86 / Debug / Arrowgrass Reports.exe" a "bin / Debug / Arrowgrass Reports.exe". El proceso no puede acceder al archivo ''bin / Debug / Arrowgrass Reports.exe'' porque está siendo utilizado por otro proceso.
He intentado un script de precompilación para intentar eliminar este archivo, pero está bloqueado por Visual Studio.
Hay algunas referencias a esto en la red por lo que es un problema conocido. ¿Alguien tiene una revisión o solución efectiva?
Para Windows Project
El proceso de alojamiento de Visual Studio puede contener el puntero del archivo ejecutable. Para detener la instancia de host, abra las Project properties del Project properties y luego vaya a la pestaña Debug . Ahora desmarque la opción Enable the Visual Studio hosting Process y luego marque la casilla nuevamente para depurar.
Para proyecto web
IIS puede contener el puntero del archivo. Reiniciar el IIS puede resolver el problema.
A partir de octubre de 2012, todavía tengo ese problema, por lo que VS 2010 SP1 no resolvió el problema. Lo que hice, y trabajé consistentemente, fue deshabilitar el proceso de alojamiento en los proyectos.
Para deshabilitar el proceso de alojamiento:
. Open a project in Visual Studio.
. On the Project menu, click Properties.
. Click the Debug tab.
. Clear the Enable the Visual Studio hosting process check box.
Fuente: http://msdn.microsoft.com/en-us/library/ms185330(v=vs.100).aspx
Agregando lo siguiente al evento Pre-build del dll compartido funcionó para mí:
if exist "$(TargetPath).locked*" del "$(TargetPath).locked*"
set exitprebuildfor$(ProjectName)=
for /l %%a in (1,1,10) do (
if defined exitprebuildfor$(ProjectName) goto :ok
if not exist "$(TargetPath).locked%%a" if exist "$(TargetPath)" move "$(TargetPath)" "$(TargetPath).locked%%a" & set exitprebuildfor$(ProjectName)=1)
:ok
set exitprebuildfor$(ProjectName)=
Se basa en la solución dada here pero en lugar de simplemente cambiarle el nombre a dll por .locked, sigue intentando cambiarle el nombre a .locked1, locked2. Con 10 usualmente encuentro el problema una vez al día, pero se puede usar el valor de la hormiga.
Borre su carpeta Bin y ejecute la aplicación. Esto funcionó para mí. :)
Compruebe el Administrador de tareas para el proceso especificado y finalice el proceso de forma explícita. Esta solución funcionó para mí.
Creo que acabo de encontrar al culpable y la solución.
Vaya a los servicios y detenga y deshabilite el servicio de "búsqueda de Windows".
Eso resolvió el problema para mí ahora.
Detenga el servicio de IIS y trate de compilarlo de nuevo o si puede permitirse reiniciar su PC, pruébelo. Funcionó para mí en ambos sentidos.
Aclamaciones
El cierre de los controles de usuario recientemente modificados resolvió el problema en mi escenario. Espero que esto ayude a alguien por ahí.
Elimine el archivo obj. Y detenga su servicio y reinicie nuevamente. Luego, puede resolver el problema.
En mi caso, hice Propiedades del proyecto -> Ficha Seguridad -> Desmarque la configuración de seguridad de hacer clic una vez (si está marcada). Funcionó para mí En mi proyecto, estaba mostrando este error para un dll C ++ que se utiliza en mi proyecto C #.
Encontré este problema al desarrollar servicios de Windows. Descubrí que sucede cuando el servicio se está ejecutando. Por lo tanto, solo necesita detener el servicio (desde la consola services.msc) y ¡ya está listo!
Espero que esto ayude. Tidjani.
He encontrado que este tema es muy fácil de reproducir, y la solución para mí es una variación de la respuesta de Richard Fors. Si tengo un UserControl abierto en el diseñador, ejecuto el depurador y luego edito el UserControl, la posterior reconstrucción fallará. Si cierro UserControl antes de ejecutar el depurador, nunca me aparece este error, así que solo me aseguro de cerrar la ventana del diseñador antes de presionar F5.
He tenido este error cuando el proyecto está en un recurso compartido remoto (por ejemplo, si su $ IT env: homepath es redirigido amablemente por su departamento de TI a un recurso compartido de red). Asegúrese de que su proyecto sea residente en un disco local.
Intente desinstalar Windows Live SYNC. ¿Todavía sucede?
Intente eliminar el archivo .exe en la carpeta de depuración o liberación (sea lo que sea que trabaje) Windows le indicará que el proceso X lo ha abierto y no puede eliminarlo luego de ir al administrador de tareas y en la pestaña de detalles tarea final X proceso
La condición descrita también puede ser causada por la DLL ofensiva o EXE que hace referencia a sí mismo; en cuyo caso, la prueba de Process Explorer descrita anteriormente nunca devuelve una coincidencia (por ejemplo, no se está ejecutando). Esta situación inesperada parece ser causada durante una secuencia de operaciones en VS2010 (y probablemente todas las versiones anteriores) que insidiosamente agrega la referencia detrás de las escenas. La causa específica de esto no se ha rastreado (o resuelto que yo sepa). Para comprobar y resolver este error, simplemente asegúrese de que el archivo DLL o EXE no aparece como una referencia a sí mismo.
La desactivación de la búsqueda de Windows no me solucionó. Sin embargo, la desactivación de antivirus lo hizo (nuestro antivirus es Symantec Endpoint Protection 11)
Como tal, pude arreglar esto por mí mismo al cambiar la configuración de depuración en el proyecto para apuntar la carpeta de trabajo a una ruta en la unidad C: y luego, exceptuar esa ruta de la configuración de exploración de autoprotección del antivirus.
Espero que esto ayude a alguien.
La mejor solución para mí fue sacar mis archivos de proyecto de Mis documentos, que está en un servidor administrado por el departamento de TI, y ubicarlos localmente en mi disco C. También funciona: desmarque la casilla de verificación "Habilitar el proceso de alojamiento de Visual Studio", como lo mencionan otras personas.
Lo que funcionó para mí fue eliminar el estado "solo lectura" en la carpeta bin. Una vez que hice eso, ha funcionado desde entonces.
Mi problema comenzó después de crear un control personalizado y arrastrarlo y soltarlo en la paleta de la caja de herramientas para usarlo en formularios de diseño. Primero apareció una advertencia que decía que había una redundancia entre el archivo fuente de control personalizado (.cs) y el ejecutable del proyecto (.exe). Al ejecutar / depurar apareció el error: no se puede acceder al (.exe) porque se está utilizando (y era cierto).
A literalmente eliminé todo el código fuente relacionado con el control personalizado y el último problema nunca se detuvo, hasta que revisé las referencias y se hacía referencia a sí mismo para poder "obtener" el control personalizado anterior. ¡Eliminé la referencia y lo hice!
Entonces: simplemente verifique las referencias y elimine la autorreferencia al proyecto.
Mi problema era que Outlook 2010 (outlook.exe) estaba usando el mismo puerto que mi proyecto ASP.NET MVC con IIS express.
Solución: cierre outlook.exe, ejecute su solución y vuelva a abrir Outlook (para que use otro puerto).
Espero que esto ayude a alguien, porque recibí el mismo mensaje de error que se describe en este tema.
No puedo escribir a un comentario ya que no está en 50 puntos, pero para mí excluí mi carpeta de proyecto en ESET Enpoint Security ver 5. Parece que bloqueó / acaparó algunos archivos. Mi error no indicó qué exe o archivo estaba en uso, por lo que tardó mucho tiempo en llegar finalmente a lo que JoeC dijo sobre Antivirus y lo probó. Parece estar funcionando ahora (Visual Studio 2010 SP1)
Obtuve el error ("El proceso no puede acceder al archivo ... porque lo está utilizando otro proceso") cuando modifiqué la solución (Visual Studio 2010 C # Express con SP1) de dos archivos fuente grandes (~ 10 líneas por archivo) proyectos con uno haciendo referencia al otro, a lotes (6) de proyectos más pequeños con muchos proyectos que hacen referencia a otros proyectos.
Las referencias fueron a los archivos dll y exe (las versiones de Debug de ellos), NO a los proyectos aunque los proyectos estaban en la misma solución.
Luego aprendí que las referencias deben ser para proyectos, no archivos, para que F12 funcione correctamente. Entonces modifiqué las referencias. Eso hizo que F12 funcionara (salta al archivo fuente en lugar de a una descripción de interfaz autogenerada), y al mismo tiempo desapareció el error "no se puede acceder al archivo" durante la compilación.
Solo recibí el error "no puedo acceder al archivo" al hacer versiones de lanzamiento. Las referencias fueron a las versiones de Debug de exe / dll''s. Sospecho que esta mezcla es lo que desencadena el error en VS.
Para mí, la solución fue cambiar el proyecto de inicio a un dll (el problema solo ocurre en el modo de depuración cuando se tiene una aplicación como proyecto de inicio). Si su solución contiene varios proyectos (y lo hará, y contendrá un .dll, de lo contrario no obtendría el problema), cambie a .dll, no .vshost.exe, no hay problema.
Además, matar .vshost.exe no funcionó para mí, ya que inmediatamente después de volver a iniciar, había bloqueado el archivo .dll.
Además, asegúrese de tener sus referencias limpias, especialmente en proyectos más complejos, y también prefiera las referencias de proyectos a las referencias de ensamblaje, y así sucesivamente. Supongo que las malas referencias (circulares y similares) pueden causar problemas, al menos así lo he leído.
Parece que este problema (¡finalmente!) Se ha solucionado en el VS2010 SP1
Publiqué esta respuesta en una pregunta similar, pero pensé que también lo diría aquí:
Bien ... esto puede sonar bastante loco.
He tenido este problema en VS2010 durante los últimos años. La solución aquí mencionada funciona para mí, pero muchas veces olvidé cerrar todos mis formularios / controles de usuario primero.
Descubrí que simplemente voy a ver los archivos abiertos a través de:
Computer Management (compmgmt.msc)->Shared Folders->Open Files
"Liberará" el archivo que esté siendo bloqueado. ¡Muy extraño, pero funciona para mí!
Puede intentar eliminar el proceso vshost.exe:
taskkill /F /IM "Arrowgrass Reports.vshosts.exe"
También puede tener suerte y simplemente ser capaz de mover el archivo en cuestión. Mover el archivo se puede hacer agregando las siguientes líneas de código al 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"
Si está trabajando en un proyecto C # que está utilizando la referencia de C DLL, puede eliminar el error marcando la casilla de verificación Permitir código inseguro. Sé que no he usado punteros en mi proyecto C # pero estaba usando un operador bit a bit en C #. Puede ser que estas características tipo C lo hayan transformado en un código "inseguro".
Simplemente apague el alojamiento de Visual Studio en depuración, ejecute el proyecto y vuelva a ejecutarlo y ejecute el proyecto.
Abra un proyecto en Visual Studio.
. En el menú Proyecto, haga clic en Propiedades.
. Haga clic en la pestaña Depurar.
. Desactive la casilla de verificación Habilitar el proceso de alojamiento de Visual Studio
Simplemente haga una copia de todo el proyecto y ejecute el proyecto desde la nueva copia ... funcionará bien. Pero tendrá que finalizar el proceso de depuración de alguna manera para eliminar el proyecto anterior.