Je travaille sur une solution composée de 8 projets .NET. Depuis que je pratique TDD, je dois ré-compiler ma solution très souvent. Dernièrement, j'ai eu l'erreur suivante à propos de chaque seconde en essayant de compiler:
erreur 2 Impossible de copier le fichier "obj \ débogueur \ zeiterfassung.tests.dll" à "bin \ debug \ zeiterfassung.tests.dll". Le processus ne peut pas accéder au fichier 'bin \ debug \ zeiterfassung.tests.dll' parce qu'il est utilisé par un autre traiter.
zeiterfassung.tests.dll est la DLL générée par l'un de mes projets (c'est le projet de test de l'unité). 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 à nouveau ma solution. Mais lorsque le problème devient vraiment mauvais, le projet ne compilera tout simplement pas avec succès, peu importe la fréquence à laquelle j'essaie et que je dois redémarrer l'IDE.
J'ai utilisé la poignée de Microsoft 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é avant de redémarrer l'IDE.
Enfin, j'ai essayé d'ajouter
True à mon projet comme suggéré dans un autre forum, mais cela n'a pas aidé. aide s'il vous plaît! Ce problème commence vraiment à me conduire des noix.
EDIT: J'ajouterais également que je me suis assuré que mes tests de l'unité sont terminés lorsque ce problème se produit. Néanmoins, la dll reste verrouillée. Je passe mes tests via l'explorateur de test de l'unité Resharper.
7 Réponses :
J'ai déjà fait face au même problème. Explorateur de processus est capable de supprimer la poignée.
Vous avez raison! Mais comment puis-je l'automatiser? Le problème se produit si souvent que la fermeture de la poignée de processExplorer est trop au-dessus de la tête.
Deux choses. L'explorateur de processus aurait dû indiquer quel processus avait le fichier ouvert. Était-ce un débogage du processus avec un fil lâche? Visual Studio lui-même? Deuxièmement, la seule fois où mon équipe a un problème avec la chose "DLL Verrouillage" est lorsque nous avons une référence circulaire dans le projet. Le projet A nécessite B nécessite C, ce qui nécessite A. Visual Studio lui-même est généralement celui avec la DLL enfermée.
Visual Studio lui-même a la DLL verrouillée. Mais je ne pouvais trouver aucune référence circulaire.
Le problème le plus probable est un problème de filetage. Vous avez probablement eu un fil itinérant qui exécute toujours, et il a la référence au .dll.
Merci pour l'indice, mais comment puis-je résoudre le problème?
Adrian, votre projet utilise-t-il des capacités de multhreading d'une sorte? La question 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 de suggérer une solution à ce stade.
Non, je n'utilise aucun multithreading explicite dans mon projet. Ma solution consiste en un projet ASP.NET MVC, un projet de test unitaire et de nombreuses bibliothèques de classe. Aucun de mon code ne traite explicitement de multithreading.
Visual Studio a eu un ou plusieurs problèmes comme celle-ci depuis le jour 1. Il serait agréable de vous donner un ensemble de solutions simples qui fonctionnent toujours, mais franchement, parfois, il vient de "trébucher sur ses propres pieds". / p>
Dans ce cas, la solution simple consiste à quitter et à redémarrer. Même la fermeture de la solution et la réouverture peut ne pas aider.
Oui, c'est ce que j'ai fait jusqu'à présent. Mais avoir à redémarrer l'IDE toutes les 10 minutes a gravement une incidence sérieusement ma productivité.
par " j'ai essayé d'ajouter fidèle à mon projet comme suggéré dans un autre forum " Voulez-vous que vous ayez créé une propriété nommée GenerateSourCeneverlockTypeAsSemplies et définissez-le sur True comme suggéré à Sayed Ibrahim Hashimi
Oops, a oublié de marquer la balise GenerateSurCeneverlockSaseAssémie de vue comme code et il n'a donc pas été montré comme tel dans mon affichage. Oui, c'est ce que j'ai déjà essayé.
On dirait que le bogue disparu (doigts croisés ...) Après avoir déplacé mon projet de test, vérifiez une version antérieure du projet à partir du référentiel et a remplacé tous les fichiers de code avec les versions plus récentes.
Si cela fonctionnait, 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 maintenant supprimé. Cela pourrait conduire à l'instabilité plus tard.
Cela me semble plutôt que j'avais introduit un problème qui a conduit à ce problème au cours des derniers jours et j'ai maintenant supprimé la question avec mon code en revenant à la version précédente du code.
Cela a fonctionné pour moi: 1) créer un nouveau dossier en dehors du projet (C: \ Debug); 2) Cliquez avec le bouton droit sur votre projet et sélectionnez Propriétés. 3) localiser l'onglet de construction; 4) accédez à la section de sortie dans l'onglet Build (dernier au VS2010); 5) Cliquez sur le bouton Parcourir et sélectionnez votre nouvel emplacement C: \ Débogage en tant que répertoire de sortie; 6) Enregistrez tous les changements; 7) Construire (F6);
J'ai eu un problème similaire . Je ne connais pas d'une belle solution, mais un piratage qui résout le problème consiste à ajouter un événement de pré-construction qui tue Vstest.executionengine.exe: