Visual Studio 2008 verrouille DLL dans le dossier bin et ne le lâche pas

Je travaille sur une solution composée de 8 projets .NET. Comme je pratique TDD, je dois recompiler ma solution très souvent. Dernièrement, je suis obtiens l'erreur suivante au sujet de chaque seconde fois en essayant de compiler:Visual Studio 2008 verrouille DLL dans le dossier bin et ne le lâche pas

Erreur 2 Impossible de copier le fichier « obj \ Debug \ Zeiterfassung.Tests.dll » à « bin \ Debug \ Zeiterfassung. Tests.dll ". Le processus ne peut pas accéder au fichier 'bin \ Debug \ Zeiterfassung.Tests.dll' car il est utilisé par un autre processus .

Zeiterfassung.Tests.dll est la DLL générée par l'un de mes projets (il s'agit du projet de tests unitaires). C'est toujours cette DLL qui ne peut pas être copiée et provoque l'erreur. Tout le reste fonctionne bien 100% du temps.

Dans environ 9/10 fois je peux "résoudre" le problème en recompilant ma solution à nouveau. Mais quand le problème devient vraiment mauvais, le projet ne compilera pas avec succès, peu importe combien de fois j'essaie et je dois redémarrer l'EDI.

J'ai utilisé Microsoft handle.exe pour déterminer quel processus verrouille la DLL et c'est devenv.exe. J'ai également essayé de supprimer la DLL à la main et il ne peut vraiment pas être supprimé jusqu'à ce que je redémarre l'IDE.

Enfin et surtout, j'ai essayé d'ajouter <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies> à mon projet comme suggéré dans un autre forum, mais cela n'a pas aidé.

Aidez s'il vous plaît! Ce problème commence vraiment à me rendre fou.

Editer: Je pourrais également ajouter que je me suis assuré que mes tests unitaires sont terminés lorsque ce problème se produit. Pourtant, la DLL reste verrouillée. J'exécute mes tests via l'explorateur de test de l'unité Resharper.

Source

2009-07-21 Adrian Grigore

On dirait que le bug a disparu (doigts croisés ...) après avoir déplacé mon projet de test, j'ai extrait une version antérieure du projet du référentiel et remplacé tous les fichiers de code par les versions plus récentes.

Source

2009-07-22 12:14:12

Si cela a fonctionné, cela m'inquiète. Cela signifie que vous avez un problème dans votre code quelque part que vous avez accidentellement ajouté et que vous avez supprimé. Cela pourrait conduire à l'instabilité plus tard. – Randolpho

Il me semble plutôt que j'avais introduit un problème qui a conduit à ce problème au cours des derniers jours et maintenant j'ai supprimé le problème avec mon code en revenant à la version précédente du code. –

Peut-être que vous avez juste besoin de redémarrer, vous utilisez Windows lol. –

J'ai déjà rencontré le même problème. Process Explorer est capable de supprimer la poignée.

Source

2009-07-21 21:38:16

Vous avez raison! Mais comment puis-je automatiser cela? Le problème se produit si souvent que la fermeture du handle dans ProcessExplorer est beaucoup trop lourde. –

Deux choses. L'explorateur de processus aurait dû indiquer quel processus avait ouvert le fichier. Était-ce un débogage du processus avec un fil libre? Visual Studio lui-même? Deuxièmement, la seule fois où mon équipe a un problème avec le verrouillage des DLL, c'est quand nous avons une référence circulaire dans le projet. Projet A nécessite B nécessite C qui nécessite A. Visual Studio lui-même est généralement celui avec la DLL verrouillée. –

Visual Studio lui-même a la DLL verrouillée. Mais je n'ai pas trouvé de référence circulaire. –

Le problème le plus probable est un problème de thread. Vous avez probablement eu un thread itinérant qui est toujours en cours d'exécution, et il a la référence au fichier .DLL.

Source

2009-07-21 21:39:41 Randolpho

Merci pour l'indice, mais comment puis-je résoudre le problème? –

Adrian, votre projet utilise-t-il des capacités de mulithreading? Le problème est probablement dans le code de votre application quelque part. –

@Adrian: Comme le suggère Spencer, si vous utilisez des threads, le correctif serait dans votre code. Il y a trop de possibilités pour suggérer une solution à ce stade. – Randolpho

Visual Studio a rencontré un problème comme celui-ci depuis le premier jour. Il serait bien de vous proposer un ensemble de solutions simples qui fonctionnent toujours, mais franchement, il vient parfois de "trébucher sur ses propres pieds".

Dans ce cas, la solution simple est de quitter et redémarrer. Même la fermeture de la solution et la réouverture peuvent ne pas aider.

Source

2009-07-21 21:52:07

Oui, c'est ce que j'ai fait jusqu'ici. Mais le redémarrage de l'EDI toutes les 10 minutes a un impact important sur ma productivité. –

Par « j'ai essayé d'ajouter fidèle à mon projet comme suggéré dans un autre forum » voulez-vous dire que vous avez créé une propriété nommée GenerateResourceNeverLockTypeAssemblies et mettre à vrai comme l'a suggéré à http://social.msdn.microsoft.com/Forums/en-US/msbuild/thread/6f76db9a-ea37-42b3-a016-571912c28032? Si non, essayez cela.

Sayed Ibrahim Hashimi

Mon livre: Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build

Source

2009-07-22 02:02:11

Oups, j'ai oublié de marquer la balise GenerateResourceNeverLockTypeAssemblies comme étant du code et elle n'a donc pas été affichée comme telle dans mon message. Oui, c'est ce que j'ai déjà essayé. –

Cela a fonctionné pour moi: 1) Créer un nouveau dossier en dehors du projet (c: \ Debug); 2) Faites un clic droit sur votre projet et sélectionnez Propriétés; 3) Localiser l'onglet Construire; 4) Accédez à la section Sortie dans l'onglet Construction (le dernier dans VS2010); 5) Cliquez sur le bouton Parcourir et sélectionnez votre nouvel emplacement c: \ Debug en tant que répertoire de sortie; 6) Sauvegarder tous les changements; 7) Construire (F6);

Source

2010-11-10 00:56:48

J'avais un similar problem. Je ne connais pas de bonne solution, mais un hack qui résout le problème consiste à ajouter un événement de pré-construction qui tue vstest.executionengine.exe:

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

Source

2013-05-24 10:41:15 Wilbert

Visual Studio 2008 verrouille DLL dans le dossier bin et ne le lâche pas

Répondre

Questions connexes