Erreur: impossible d'accéder au fichier bin / Debug /… car il est utilisé par un autre processus


113

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 \ My Dream.exe "car il est utilisé par un autre processus."

En utilisant Process Explorer, je vois que MyApplication.exe était sorti mais que le processus système l'utilise toujours même si j'ai arrêté le débogage avant. Chaque fois que je change mon code et que je lance le débogage, cela se produit. Si je copie le projet sur USB et le débogage, il fonctionne correctement.

Pourquoi? Comment puis-je corriger cette erreur?

J'utilise Window 7 Professional. Avec Xp, je n'ai jamais eu cette erreur.


1
win7 maintient parfois des verrous sur les fichiers qui sont affichés dans l'explorateur, alors assurez-vous que votre dossier de débogage n'est pas ouvert.
Necrolis

Je pense que le processus système l'utilise.
Trần Minh

1
C'est soit un verrou, soit un idiot ajouté / bin au contrôle de code source, et maintenant les fichiers sont protégés en écriture (clic droit sur bin, décochez la case protégé en écriture).
Stefan Steiger

3
C'est pire dans Visual Studio 2017 que jamais auparavant.
Rob Lyndon

1
Dans mon cas, MSBuild.exej'avais une suspension sur le fichier, il suffit de terminer le processus dans le Gestionnaire des tâches
Pierre

Réponses:


120

Ugh, c'est un vieux problème, quelque chose qui apparaît toujours dans Visual Studio de temps en temps. Cela m'a mordu plusieurs fois et j'ai perdu des heures à redémarrer et à me battre avec VS. Je suis sûr que cela a été discuté ici sur SO plus d'une fois. 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 vos recherches ici .

Ce qui se passe, c'est que 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 qu'il puisse le recréer lorsque vous reconstruisez l'application. La seule solution apparente consiste à fermer et redémarrer VS afin qu'il libère le verrou sur le fichier.

Ma solution originale de contournement était d'ouvrir le dossier bin / Debug et de 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, ce qui vous permet de continuer à travailler sans avoir à fermer toutes vos fenêtres et à attendre que VS redémarre. Certaines personnes ont même automatisé cela en utilisant un événement de pré-construction pour ajouter une chaîne aléatoire à la fin de l'ancien nom de fichier de sortie. Oui, c'est un hack géant , mais ce problème devient tellement frustrant et débilitant que vous ferez n'importe quoi.

J'ai appris plus tard, après un peu plus d'expérimentation, que le problème ne semble surgir que lorsque vous construisez le projet avec l'un des concepteurs ouvert. Donc, la solution qui a fonctionné pour moi à long terme et qui m'a empêché de faire face à l'une de ces erreurs stupides à nouveau est de s'assurer que je ferme toujours toutes les fenêtres de concepteur avant de créer un projet WinForms. Oui, cela aussi est quelque peu gênant, mais cela ne vaut pas le coup 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'y ai pas personnellement rencontré le problème.

Je n'ai pas encore essayé de le reproduire sur VS 2012 RC. Je ne sais pas si cela a encore été corrigé ou non. Mais mon expérience jusqu'à présent a été qu'il parvient toujours à apparaître même après que Microsoft a prétendu l'avoir réparé. Il 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 pense qu'il y a juste plusieurs causes pour le bogue et / ou qu'il est très difficile à reproduire de manière fiable dans un laboratoire. C'est la même raison pour laquelle je n'ai pas personnellement déposé de rapport de bogue à ce sujet (bien que j'aie +1 d'autres personnes), parce que je n'arrive pas à le reproduire de manière fiable, un peu comme l'Abominable Snowman.

<fin de coup de gueule qui ne vise personne en particulier>


1
Cela se produit encore (pour moi) dans VS2013. C'est toujours le fichier PDB du projet WPF dans ma solution qui est verrouillé dans le répertoire cible. Fermer tous les concepteurs n'a pas fonctionné (boo!) Mais renommer le fichier (merci, Cody!). Un hack géant fait signe ...
Jon

2
Cela a commencé à m'arriver depuis hier lorsque je suis passé à vS 2013 ... cela ne m'était pas arrivé une seule fois depuis VS 2008 ... tellement triste.
SomeNickName

8
VS 2015, et j'ai toujours le problème.
Berin Loritsch

13
Cela se produit dans Visual Studio 17 et le redémarrage de Visual Studio n'aide pas.
Rob Lyndon

2
@jairhumberto aucune raison pour le snark, les ordinateurs sont assez frustrants comme ça, pas besoin de transmettre ça à quelqu'un d'autre .. mais cela fonctionne pour moi pour ce problème spécifique, peut-être que vous avez quelque chose de différent! Voir: stackoverflow.com/a/19649014/27494
ScottN

64

J'ai déjà eu cette erreur sur moi, 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"

1
Où puis-je trouver cet Pre-Buildévénement sur mon formulaire Windows?
Unknownymous

2
@qwerty Il se trouve dans les propriétés du projet sous la section Build Events ou si vous êtes sur le projet VB.net, sous la section Compile, vous verrez un bouton Build Events.
ScottN

@ScottN: oh BTW, ce pre-buildcode est également le remède pour l'application déployée (via un clic) lorsque mon application est en cours d'exécution puis un bogue / pépin s'est produit puis sur le gestionnaire de tâches, je terminerai la tâche myApp.exemais je ne terminerai pas la tâche et l'invite ERROR ON ENDING TASK?
Unknownymous

@qwerty Non, cela n'a aucune association avec une application déployée ClickOnce. Cette erreur se produit uniquement lorsque vous créez votre application pendant le développement et les tests et uniquement dans Visual Studio, pas pour les applications déployées s'exécutant sur les systèmes clients.
ScottN

À quoi fait .lockedréférence?
Shimmy Weitzhandler

22

Ordinateur (clic droit) -> gérer -> Service et application -> service -> Activer l'expérience d'application

A travaillé pour moi!


2
J'avais désactivé ce service il y a quelques mois. L'activer maintenant semblait résoudre le problème dans Visual Studio (impossible de copier en raison du verrouillage du fichier exe). Je me demande pourquoi ce service doit fonctionner, ce que j'ai lu à ce sujet ne semble pas lié à quoi que ce soit de pertinent pour cette erreur (par exemple. Blackviper.com/windows-services/application-experience ).
Andreas Jansson

10
J'ai ce service en cours d'exécution mais j'ai toujours le problème de verrouillage.
antfx

1
+1 Wow, j'ai essayé / tout / autre que j'ai trouvé. Finalement, je suis tombé dessus pour le réparer. Le mien a également été désactivé. Je n'aurais jamais pensé que c'était le coupable!
John S.

L'exécution de Windows 7 SP1 avec VS2010 SP1, l'activation des services «Application Experience» m'aide immédiatement. Merci beaucoup. Mais une minute plus tard, l'éteindre ne reproduit pas immédiatement le problème.
Jimm Chen

7
service introuvable dans Windows 10
JerryGoyal

13

J'ai eu le même problème dans Visual Studio 2013. Je ne suis pas sûr de la cause de ce problème pour mon projet, mais j'ai pu le résoudre en nettoyant la solution et en la reconstruisant.

  1. Construire> Solution propre
  2. Construire> Reconstruire la solution

1
Ne l'essayez pas sur de gros projets ... La reconstruction complète prend très longtemps.
mBardos

7

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 provoquent apparemment des verrous de fichiers.

Tuer msbuild.exe est une solution ponctuelle, elle doit être effectuée par build.

Mais ensuite, j'ai compris 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 maximum de constructions de projets parallèles" - par défaut, il a la valeur de 8, je 'ai changé à 1. Fonctionne comme un charme.

Bien sûr, les builds sont un peu plus lents 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.


7

Je comprends que c'est une vieille question. Malheureusement, j'étais confronté au même problème avec ma .net core 2.0candidature au format visual studio 2017. J'ai donc pensé à partager la solution qui fonctionnait pour moi. Avant cette solution, j'avais essayé les étapes ci-dessous.

  1. Studio visuel redémarré
  2. Fermé toute l'application
  3. Nettoyer ma solution et reconstruire

Aucune des étapes ci-dessus n'a résolu le problème.

Et puis j'ai ouvert mon processus et Task Managersélectionné, puis j'ai dotnetcliqué sur le bouton Fin de la tâche. Plus tard, j'ai ouvert mon Visual Studio et tout fonctionnait bien.

entrez la description de l'image ici


2

Voir ma réponse ici si vous rencontrez ce problème lors de l'exécution de tests unitaires. Réponse copiée ci-dessous:

Sur la base de la réponse de Sébastien, j'ai ajouté une étape de pré-construction à mon projet de test pour tuer automatiquement tous les vstest.*exécutables encore en cours d'exécution. La commande de pré-construction suivante a fonctionné pour moi:

taskkill /f /im vstest.*
exit 0

La exit 0commande est à la fin pour empêcher l'échec de la construction lorsqu'il n'y a pas d' vstest.*exécutables en cours d'exécution.


1

Récemment, j'ai eu 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 tout 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é "Contrats de code" et que vous l'avez activé, cela prend parfois vos DLL pour vérifier et raccrocher sur cette opération.

Donc, vous devez arrêter tous les processus de "CCCheck.exe" et c'est tout.

Enfin, pour comprendre que le processus utilise votre DLL, vous pouvez toujours essayer de supprimer simplement le dossier «obj» dans votre gestionnaire de fichiers et cette opération échouera, vous pouvez voir la «fenêtre de message» avec la description de l'opération de blocage. Aussi, en variante, vous pouvez essayer d'utiliser l'application "Sys Internals Suite".


Au moins dans mon cas, j'ai remarqué que Visual Studio créait des processus fantômes msbuild.exe, qui ne périssaient pas après la construction. Ces zombies provoquent apparemment des verrous de fichiers. Mais aucune idée de la façon de le résoudre. Tuer msbuild.exe est une solution ponctuelle, elle doit être effectuée par build.
TarmoPikaro

1

A 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; Win 8;


1

Assurez-vous que toute exécution précédente de l'application (par exemple, démarrer sans option de débogage) est effectivement arrêtée. Je travaillais sur une application WPF, j'ai commencé sans débogage et je l'ai minimisée lorsque j'ai continué à recevoir l'erreur. Après la fermeture de l'application, le comportement VS est revenu à la normale.


1

J'ai été en proie à ce problème dans Visual Studio 2017. Cela a commencé il y a environ deux ou trois semaines et a gravement rongé 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 le problème consiste à nettoyer l'assembly incriminé et à générer (au lieu de 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 est probablement d'ouvrir une invite de commande de développeur et de l'utiliser msbuilddirectement. Je fais cela depuis trois jours et jusqu'à présent, le problème n'est pas arrivé une seule fois.


1

Dans mon cas, j'ai activé "Afficher tous les fichiers". Visual Studio 2017


1

Courez taskmanager.
Localisez-le netcoreet supprimez-le.
Vous pouvez ensuite supprimer le fichier manuellement ou en exécutant Clean.


0

C'est de la pure spéculation et non une réponse.

Cependant, j'ai ce problème depuis un certain temps.

Je suis venu après un certain temps pour soupçonner une interaction entre VS et mes précautions AV.

Après un certain jeu, il semble qu'il peut avoir disparu quand je modifié mon antivirus afin que tout sous la

C: \ Users [nom d'utilisateur] \ AppData \ Local \ Microsoft \ VisualStudio \ 10.0 \ ProjectAssemblies

dossier n'était pas inclus dans la protection en temps réel.

Il semble que la construction écrit d'abord la DLL ici, puis la copie dans l'emplacement de construction final.


0

Cela pourrait être trop tard. Mais, j'ai rencontré un problème similaire et dans mon cas, le projet avait une référence personnelle. Par conséquent, le supprimer des références a fonctionné comme un charme !!!


0

J'ai trouvé le moyen le plus rapide sans fermer les formulaires ou redémarrer VisualStudio est d'aller sur la page de compilation du projet et de cliquer sur le bouton "Options de compilation avancées ...". Ensuite, modifiez l'une des options (par exemple, en changeant Générer les informations de débogage de Complet à pdb uniquement), puis cliquez sur OK. Cela fonctionne à chaque fois et devra faire jusqu'à ce que MS corrige ce bug (je n'ai jamais eu ce problème jusqu'à ce que je passe de VS2012 à VS2013)

Une autre note, si vous ne pouvez pas nettoyer le projet ou la solution, il ne sera pas généré. Les fichiers sont définitivement verrouillés par VS (pas un problème d'antivirus, du moins pas dans mon cas)


0

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.


0

J'ai rencontré le même problème et ce que j'ai trouvé, c'est qu'il existe en fait plusieurs applications de formulaire Windows en arrière-plan. Cela se produit lorsque votre application comporte deux formulaires et que vous fermez le deuxième formulaire qui n'est pas votre formulaire principal, de sorte que l'application ne sera pas totalement fermée.

Je lance généralement mon application

  • via son exe ou
  • exécuter sans débogage

La solution est de fermer l'autre instance de l'application de formulaire Windows . C'est une façon de toujours fermer votre instance d'application.


0

Commande de pré-construction

(if exist "$(TargetDir)*old.pdb" del "$(TargetDir)*old.pdb") & (if exist "$(TargetDir)*.pdb" ren "$(TargetDir)*.pdb" *.old.pdb)

Aidé


0

[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 pendant que vous essayiez d'exécuter deux fenêtres l'une après l'autre, comme le premier chargement d'un formulaire, puis parfois, il disparaîtra automatiquement et le second formulaire chargé sur 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.


0

Une solution simple est d'aller dans le dossier bin \ Debug, de supprimer tous les fichiers de ce dossier, puis de reconstruire. Si cela ne fonctionne pas, fermez Visual Studio puis allez dans le dossier bin \ Debug à l'aide de l'explorateur de fichiers, sur le côté gauche, cliquez sur Fichier> Ouvrir l'invite de commande> Ouvrir l'invite de commande en tant qu'administrateur> Entrez cette commande "DEL / F / Q / A * "> puis reconstruire


0

J'ai trouvé la réponse de Cody Gray partiellement utile, dans la mesure où elle m'a dirigé vers la source réelle de mon problème que certains d'entre vous peuvent également rencontrer: l'exécution des tests de Visual Studio reste ouverte par défaut et maintient un verrou sur les fichiers.

Pour arrêter ce comportement principalement 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 -> "Maintenir le moteur d'exécution de test en marche"


0

Mon problème était que dotnet était bloqué et chaque fois que VS essayait de créer une nouvelle dll, ou d'accéder à une ancienne, le processus dotnet se bloquait sur la dll et empêchait Visual Studio de cloner la dll. La solution consiste simplement à mettre fin à toutes les tâches dotnet dans le gestionnaire de tâches (cela ne supprimera réellement que la tâche morte, si vous essayez d'en terminer une et qu'elle ne s'arrête pas, cela signifie que cela fonctionne).


0

Fermez VisualStudio, ctrl-alt-delete, sélectionnez Gestionnaire de tâches, recherchez et terminez tous les processus MSBuild - VisualStudio a fondamentalement un bogue assez grave où 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 terminé 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 doit réparer cette merde.


0

J'ai ouvert une 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.

J'ai ajouté le dossier bin à la liste d'exclusion de l'antivirus, redémarré la machine et maintenant cela semble fonctionner.


0

J'ai résolu ce problème.

près du débogage, vous voyez un menu déroulant avec une configuration. Par défaut, il y avait n'importe quel processeur. Sélectionnez x86 et exécutez le programme, il fonctionnera. Si x86 n'est pas là, allez dans le gestionnaire de configuration et ajoutez le x86


-1

Un autre kludge, ugh, mais c'est facile et fonctionne pour moi dans VS 2013. Cliquez sur le projet. Dans le panneau des propriétés doit être une entrée nommée Fichier de projet avec une valeur

(nom de votre projet) .vbproj

Modifiez le nom du projet, par exemple en ajoutant un -01 à la fin. Le fichier .zip d'origine qui a été verrouillé est toujours là, mais n'est plus référencé ... afin que votre travail puisse continuer. Au prochain redémarrage de l'ordinateur, ce verrou disparaît et vous pouvez supprimer le fichier errant.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.