Erreur: impossible d'accéder au fichier bin / Debug / ... car il est utilisé par un autre processus
Lorsque je débogue mon projet, j'obtiens l'erreur suivante:
"Impossible de copier le fichier" obj\Debug\My Dream.exe "vers" bin\Debug\My Dream.exe ". Le processus ne peut pas accéder au fichier 'bin\Debug\Mon Dream.exe' car il est utilisé par un autre processus."
À l'aide de Process Explorer, je constate que MyApplication.exe était épuisé, mais le processus système l'utilise toujours bien que j'aie arrêté le débogage auparavant. Chaque fois que je change de code et que je lance le débogage, cela se produit. Si je copie le projet sur USB et le débogage, tout se passe bien.
Pourquoi? Comment puis-je réparer cette erreur?
J'utilise Windows 7 Professional. Avec Xp, je n'ai jamais eu cette erreur.
Ugh, c'est un vieux problème, quelque chose qui apparaît encore dans Visual Studio de temps en temps. Cela m'a mordu plusieurs fois et j'ai perdu des heures à recommencer et à me battre avec VS. Je suis sûr que cela a été discuté ici plus d'une fois sur SO. On en a également parlé sur les forums MSDN. Il n'y a pas de solution réelle, mais il existe quelques solutions de contournement. - Commencez la recherche ici .
En réalité, VS acquiert un verrou sur un fichier et ne le libère pas. Ironiquement, ce verrou empêche VS lui-même de supprimer le fichier afin de pouvoir le recréer lors de la reconstruction de l'application. La seule solution apparente consiste à fermer et à redémarrer VS pour qu'il libère le verrou sur le fichier.
La solution originale consistait à ouvrir le dossier bin/Debug et à renommer l'exécutable. Vous ne pouvez pas le supprimer s'il est verrouillé, mais vous pouvez le renommer. Vous pouvez donc simplement ajouter un numéro à la fin ou quelque chose comme ça, ce qui vous permet de continuer à travailler sans avoir à fermer toutes vos fenêtres et à attendre que VS redémarre. Certaines personnes l'ont même automatisé en utilisant un événement de pré-génération pour ajouter une chaîne aléatoire à la fin de l'ancien nom de fichier en sortie. Oui, c'est un piratage géant , mais ce problème devient tellement frustrant et débilitant que vous ferez n'importe quoi.
J'ai appris par la suite, après un peu plus d'expérimentation, que le problème semblait ne surgir que lorsque vous construisez le projet avec l'un des concepteurs ouvert. Donc, la solution qui a fonctionné pour moi à long terme et m'a empêché de traiter à nouveau avec une de ces erreurs stupides est de m'assurer de toujours fermer toutes les fenêtres du concepteur avant de construire un projet WinForms. Oui, cela aussi est un peu gênant, mais cela bat le pantalon de devoir redémarrer VS deux fois par heure ou plus.
Je suppose que cela s'applique également à WPF, bien que je ne l'utilise pas et que je n'ai pas personnellement rencontré le problème là-bas.
Je n'ai pas non plus essayé de le reproduire sur le VS 2012 RC. Je ne sais pas si ça a déjà été corrigé ou pas. Mais mon expérience jusqu’à présent est qu’il parvient toujours à apparaître même après que Microsoft a prétendu l’avoir réparé. C'est toujours là dans VS 2010 SP1. Je ne dis pas que leurs programmeurs sont des idiots qui ne savent pas ce qu'ils font, bien sûr. Je suppose que le bogue a plusieurs causes et/ou qu’il est très difficile de se reproduire de manière fiable en laboratoire. C'est la même raison pour laquelle je n'ai personnellement pas fait de rapport de bogue (bien que je sois revenu de plus d'un autre peuple), parce que je n'arrive pas à le reproduire de manière fiable, un peu comme le bonhomme de neige Abominable.
<fin de diatribe qui est dirigée vers personne en particulier>
J'ai déjà eu cette erreur auparavant, même dans Visual Studio 2008. Elle est revenue et plus répandue dans Visual Studio 2012.
Voici ce que je fais.
Collez ceci dans l'événement de pré-construction du projet gênant:
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
Ordinateur (clic droit) -> Gérer -> Service et application -> Service -> Activer l'expérience de l'application
Travaillé pour moi!
J'avais le même problème dans Visual Studio 2013. Je ne suis pas sûr de la cause de mon projet, mais j'ai pu le résoudre en nettoyant la solution et en le reconstruisant.
- Construire> Solution propre
- Construire> Reconstruire la solution
Au moins dans mon cas, j'ai remarqué que Visual Studio 2012 créait au moins deux processus fantômes msbuild.exe, qui ne périssaient pas après la construction. Ces zombies sont apparemment à l’origine de verrous de fichiers.
Tuer msbuild.exe est une solution ponctuelle, il faut le faire par construction.
Mais je me suis dit que je pouvais désactiver la construction parallèle une fois pour toutes - je suis allé dans Outils> Options> Projets et solutions> Construire et exécuter> "nombre maximal de constructions de projets parallèles" - par défaut, la valeur est 8, I 'suis passé à 1. Fonctionne comme un charme.
Bien sûr, les constructions sont un peu plus lentes maintenant, mais mieux vaut prévenir que guérir. Au moins pour ce petit projet particulier, je n'avais pas besoin de plus d'un thread de construction.
Je comprends que c'est une vieille question. Malheureusement, je faisais face au même problème avec mon .net core 2.0 application dans visual studio 2017. J'ai donc pensé à partager la solution qui fonctionnait pour moi. Avant cette solution, j'avais essayé les étapes ci-dessous.
- Visual studio redémarré
- Fermé toute l'application
- Nettoyer ma solution et reconstruire
Aucune des étapes ci-dessus n'a pas résolu le problème.
Et puis j'ai ouvert mon Task Manager et sélectionné dotnet processus, puis cliquez sur le bouton Terminer la tâche. Plus tard, j'ai ouvert mon Visual Studio et tout fonctionnait bien.
Voir ma réponse ici si vous rencontrez ce problème lors de l'exécution des tests unitaires. Réponse copiée ci-dessous:
En me basant sur la réponse de Sébastien, j'ai ajouté une étape de pré-construction à mon projet test pour tuer automatiquement tout
vstest.*exécutables toujours en cours d'exécution. La commande de pré-construction suivante a fonctionné pour moi:taskkill /f /im vstest.* exit 0Le
exit 0La commande est à la fin pour empêcher l’échec de la construction quand il n’ya pas devstest.*exécutables en cours d'exécution.
Assurez-vous que toute exécution précédente de l'application (par exemple, démarrer sans option de débogage) est réellement arrêtée. Je travaillais sur une application WPF, j'ai démarré sans débogage et je l'ai minimisé lorsque j'ai continué à avoir l'erreur. Après la fermeture de l'application, le comportement du VS est revenu à la normale.
Travaillé pour moi Gestionnaire de tâches -> Nom du projet -> Fin de tâche. (J'ai eu 3 mêmes processus avec mon nom de projet);
VS 2013; Gagner 8;
Récemment, j'ai rencontré un problème avec Visual Studio 2012 avec la même description d'erreur: "Le processus ne peut pas accéder au fichier car il est utilisé par un autre processus ..."
Pour résoudre ce problème, vous devez d'abord comprendre l'application qui l'utilise encore. J'ai arrêté tous les processus tels que "MSBuild" et "MSBuild Host". Mais ce n'est pas assez. Si vous avez installé "Code Contracts" et activé, il faut parfois vos DLL pour vérifier et mettre fin à cette opération.
Donc, vous devez arrêter tous les processus de "CCCheck.exe" et c'est tout.
Enfin, pour comprendre que ce processus utilise votre DLL, vous pouvez toujours essayer de simplement supprimer le dossier "obj" de votre gestionnaire de fichiers et cette opération échouera. La "fenêtre de message" avec sa description peut s'afficher. En variante, vous pouvez également utiliser l’application "Sys Internals Suite".
Dans mon cas, c’est que j’ai activé "Afficher tous les fichiers". Visual Studio 2017
Ce problème me préoccupe dans Visual Studio 2017. Cela a commencé il y a deux ou trois semaines et a gravement compromis ma productivité. Clean et Rebulid n'ont pas fonctionné. Même le redémarrage de ma machine ne fait pas le travail.
Une façon de résoudre ce problème consiste à nettoyer l’ensemble défectueux et à construire (au lieu de le reconstruire) le projet que vous souhaitez exécuter immédiatement après. Cela fonctionne environ 30% du temps.
Cependant, la solution la plus fiable que j'ai trouvée consiste probablement à ouvrir une invite de commande du développeur et à utiliser msbuild directement. Je fais cela depuis trois jours et jusqu'à présent, le problème ne s'est pas posé une seule fois.
Exécutez taskmanager.
Localisez netcore et supprimez-le.
Vous pouvez ensuite supprimer le fichier manuellement ou en exécutant Clean.
la réponse de Cody Gray a été partiellement utile, car elle m’a dirigé sur la source réelle de mon problème que certains d’entre vous rencontrez peut-être aussi: l’exécution du test de visual studio reste ouverte par défaut et maintient un verrou sur les fichiers.
Pour arrêter ce comportement essentiellement inutile, suivez les instructions de https://connect.Microsoft.com/VisualStudio/feedback/details/771994/vstest-executionengine-x86-exe-32-bit-not-closing-vs2012 -11-0-50727-1-rtmrel
Décochez le menu Test -> Paramètres de test -> "Conserver le moteur d’exécution de test en marche"
[Résolu] Erreur: Impossible d'accéder au fichier bin/Debug /… car il est utilisé par un autre processus:
J'approche que vous obtenez cette erreur alors que vous essayiez d'exécuter deux formulaires Windows l'un après l'autre, par exemple en chargeant un formulaire, puis parfois, il disparaîtra automatiquement et le second formulaire sera chargé à l'écran.
Fondamentalement, vous devez fermer votre premier formulaire qui s'exécute en arrière-plan et la principale raison de cette erreur.
Pour fermer le premier formulaire, vous devez ajouter ces deux lignes de code dans le deuxième gestionnaire d'événements de chargement de formulaire.
Form1 form = new Form1();
form.Close();
Cela résoudra parfaitement l'erreur.
J'ai trouvé le moyen le plus rapide sans fermer les formulaires ni redémarrer VisualStudio, aller à la page de compilation du projet et cliquer sur le bouton "Options de compilation avancées ...". Modifiez ensuite l'une des options (par exemple, en modifiant Générer les informations de débogage de Complet à pdb uniquement), puis cliquez sur OK. Cela fonctionne à chaque fois et il faudra le faire jusqu'à ce que MS corrige ce bogue (je n'avais jamais eu ce problème avant de passer de VS2012 à VS2013)
Autre remarque, si vous ne pouvez pas nettoyer le projet ou la solution, cela ne se construira pas. Les fichiers sont définitivement verrouillés par VS (pas un problème d'antivirus, du moins dans mon cas)
Fermez VisualStudio, ctrl-alt-suppr, sélectionnez Gestionnaire des tâches, recherchez et mettez fin à tous les processus MSBuild - VisualStudio a un bogue assez grave dans lequel il perd le contrôle de son débogueur et le débogueur maintient un verrou sur le fichier .pdb dans le débogage/bin dossier. Une fois que vous avez mis fin à tous les processus MSBuild (débogueur), supprimez le dossier/debug/bin et rouvrez votre solution dans Visual Studio. Vous êtes prêt à partir maintenant. Microsoft a besoin de réparer cette merde.
Il pourrait être trop tard. Mais, j'ai rencontré un problème similaire et dans mon cas, le projet avait une référence automatique. Par conséquent, le supprimer des références a fonctionné comme un charme !!!
Une solution simple consiste à aller dans le dossier bin\Debug, à supprimer tous les fichiers de ce dossier, puis à le reconstruire. Si cela ne fonctionne pas, fermez Visual Studio, puis accédez au dossier bin\Debug à l'aide de l'explorateur de fichiers. Sur le panneau de gauche, cliquez sur Fichier> Ouvrir une invite de commande> Ouvrir une invite de commande en tant qu'administrateur> Entrez cette commande "DEL/F/Q/A * "> puis reconstruire
Commande de pré-construction
(if exist "$(TargetDir)*old.pdb" del "$(TargetDir)*old.pdb") & (if exist "$(TargetDir)*.pdb" ren "$(TargetDir)*.pdb" *.old.pdb)
Aidé
Ceci est une pure spéculation et non une réponse.
Cependant, j'ai ce problème depuis un moment.
Je suis venu après un moment pour soupçonner une interaction entre VS et mes précautions AV.
Après avoir joué, il semble que le peut soit parti quand j'ai modifié mon antivirus pour que tout
C:\Utilisateurs [nom d'utilisateur]\AppData\Local\Microsoft\VisualStudio\10.0\ProjectAssemblies
dossier n'était pas inclus dans la protection en temps réel.
On dirait que la construction écrit en fait le DLL ici d'abord, puis la copie dans l'emplacement de construction final.
Mon problème était que dotnet était bloqué et que chaque fois que VS essayait de créer une nouvelle dll ou d'accéder à une ancienne, le processus dotnet se verrouillait sur la dll et empêchait Visual Studio de cloner la dll. La solution consiste simplement à mettre fin à toutes les tâches de type dotnet dans le gestionnaire de tâches (elle supprimera uniquement la tâche morte, si vous essayez de mettre fin à une tâche et si elle ne s'arrête pas, cela signifie que cela fonctionne).
J'ai essayé toutes ces suggestions ainsi que d'autres suggestions trouvées ailleurs et la seule chose qui a fonctionné pour moi a été de redémarrer mon ordinateur. Ensuite, j'ai fait une solution propre suivie d'une reconstruction. J'utilise Visual Studio 2013 pour référence.
J'ai couru à ce même problème, et ce que j'ai trouvé, c'est qu'il y a en train de faire tourner plusieurs applications de formulaire Windows en arrière-plan. Cela se produit lorsque votre application a deux formulaires et que vous fermez le 2ème formulaire qui n'est pas votre formulaire principal donc l'application ne sera pas totalement abandonnée.
Je lance habituellement mon application
- à travers son exe ou
- exécuter sans débogage
La solution est de fermer l'autre instance de l'application de formulaire Windows . C’est n moyen de toujours fermer votre instance d’application.
J'ai ouvert un question distincte concernant VS 2017 qui avait un comportement similaire après une mise à jour. Le problème semblait être généré par le programme antivirus bien que.
J'ai ajouté le dossier bin à la liste d'exclusion d'antivirus, redémarré la machine et maintenant, il semble fonctionner.