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 \ 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.

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>}

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"

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

A travaillé pour moi!

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

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.

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.

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.

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".

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;

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.

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.

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

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

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.

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 !!!

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)

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 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.

Commande de pré-construction

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

Aidé

[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.

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

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"

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).

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.

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.

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

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.