2009-07-21 10 views
6

Estoy trabajando en una solución que consta de 8 proyectos .NET. Como estoy practicando TDD, tengo que volver a compilar mi solución muy a menudo. Últimamente he estado recibiendo el siguiente error sobre cada segundo tiempo cuando se trata de compilar:Visual Studio 2008 bloquea dll en la carpeta bin y no lo suelta

de error 2 No se puede copiar el archivo "obj \ Debug \ Zeiterfassung.Tests.dll" a "bin \ Debug \ Zeiterfassung. Tests.dll ". El proceso no puede acceder al archivo 'bin \ Debug \ Zeiterfassung.Tests.dll' porque está siendo utilizado por otro proceso .

Zeiterfassung.Tests.dll es el dll generado por uno de mis proyectos (es el proyecto de prueba de la unidad). Siempre es esta DLL que no se puede copiar y causa el error. Todo lo demás funciona bien el 100% del tiempo.

En aproximadamente 9/10 veces puedo "resolver" el problema volviendo a compilar mi solución. Pero cuando el problema se está poniendo realmente mal, el proyecto simplemente no se compilará con éxito, sin importar la frecuencia con que lo intente, y tengo que reiniciar el IDE.

Utilicé el archivo handle.exe de microsoft para determinar qué proceso está bloqueando la DLL y es devenv.exe. También traté de eliminar la DLL a mano y realmente no se puede eliminar hasta que reinicie el IDE.

Por último pero no menos importante, traté de agregar <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies> a mi proyecto como se sugirió en otro foro, pero esto no ayudó.

Por favor ayuda! Este problema realmente me está volviendo loco.

Edit: También podría agregar que me aseguré de que mis pruebas de unidad hayan finalizado cuando se produce este problema. Aún así, el dll permanece bloqueado. Estoy ejecutando mis pruebas a través del explorador de prueba de la unidad Resharper.

Respuesta

0

Parece que el error desapareció (dedos cruzados ...) después de mover mi proyecto de prueba, comprobé una versión anterior del proyecto del repositorio y reemplacé todos los archivos de código con las versiones más recientes.

+0

Si esto funcionó, me preocupa. Significa que tienes un problema en tu código en algún lugar que has agregado accidentalmente y que ahora has eliminado. Podría llevar a la inestabilidad más tarde. – Randolpho

+0

Me parece que había presentado un problema que ocasionó este problema en algún momento de los últimos días y ahora eliminé el problema con mi código volviendo a la versión anterior del código. –

+1

Quizás solo necesites reiniciar, estás usando Windows lol. –

3

He enfrentado el mismo problema antes. Process Explorer es capaz de eliminar el mango.

+1

¡Tienes razón! Pero, ¿cómo puedo automatizar esto? El problema ocurre tan a menudo que cerrar el identificador en ProcessExplorer es demasiada sobrecarga. –

+0

Dos cosas. El Process Explorer debería haber indicado qué proceso tenía el archivo abierto. ¿Fue una depuración del proceso con un hilo suelto? Visual Studio en sí? En segundo lugar, la única vez que mi equipo tiene un problema con el bloqueo de "DLL" es cuando tenemos una referencia circular en el proyecto. El Proyecto A requiere que B requiera C, lo que requiere A. Visual Studio es el que tiene el DLL bloqueado. –

+0

Visual Studio tiene el DLL bloqueado. Pero no pude encontrar ninguna referencia circular. –

1

El problema más probable es un problema de enhebrado. Probablemente tengas un hilo itinerante que aún se está ejecutando, y tiene la referencia al .DLL.

+0

Gracias por la pista, pero ¿cómo puedo solucionar el problema? –

+1

Adrian, ¿su proyecto utiliza capacidades de mulithreading de algún tipo? El problema probablemente esté en el código de tu aplicación en alguna parte. –

+0

@Adrian: como sugiere Spencer, si está utilizando subprocesos, la corrección estaría en su código. Hay demasiadas posibilidades para sugerir una solución en este punto. – Randolpho

0

Visual Studio ha tenido uno u otro problema como este desde el día 1. Sería bueno darle un conjunto de soluciones simples que siempre funcionan, pero francamente, a veces, simplemente se ha "tropezado con sus propios pies".

En ese caso, la solución más simple es salir y reiniciar. Incluso el cierre de la solución y la reapertura pueden no ser útiles.

+2

Sí, esto es lo que he estado haciendo hasta ahora. Pero tener que reiniciar el IDE cada 10 minutos afecta seriamente mi productividad. –

0

Por "He intentado añadir fiel a mi proyecto como se sugiere en otro foro" ¿Quiere decir que usted creó una propiedad denominada GenerateResourceNeverLockTypeAssemblies y la ajuste en cierto como se sugirió en http://social.msdn.microsoft.com/Forums/en-US/msbuild/thread/6f76db9a-ea37-42b3-a016-571912c28032? Si no, prueba eso.

Sayed Ibrahim Hashimi

Mi libro: Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build

+0

Vaya, olvidé marcar la etiqueta GenerateResourceNeverLockTypeAssemblies como código y, por lo tanto, no se mostró como tal en mi publicación. Sí, eso es lo que ya probé. –

1

Esto funcionó para mí: 1) Crear una nueva carpeta fuera del proyecto (c: \ Debug); 2) Haga clic con el botón derecho en su Proyecto y seleccione Propiedades; 3) Ubique la pestaña Construir; 4) Navegue a la sección Salida en la pestaña Construir (la última en VS2010); 5) Haga clic en el botón Buscar y seleccione su nueva ubicación c: \ Debug como un directorio de salida; 6) Guarde todos los cambios; 7) Generar (F6);

0

Tuve un similar problem. No sé de una buena solución, pero un truco que resuelve el problema es agregar un evento de preconstrucción que mata a vstest.executionengine.exe:

taskkill /F /IM vstest.executionengine.exe /FI "MEMUSAGE gt 1" 
taskkill /F /IM vstest.executionengine.x86.exe /FI "MEMUSAGE gt 1" 
Cuestiones relacionadas