Erreur de construction: "Le processus ne peut pas accéder au fichier car il est utilisé par un autre processus"
J'ai une application C # webforms qui, jusqu'à aujourd'hui, fonctionnait à merveille.
Maintenant, tout à coup, chaque fois que j'essaie de lancer l'application, une erreur de verrouillage de fichier se produit:
Impossible de copier le fichier "obj\Debug\MyProject.exe" dans "bin\Debug\MyProject.exe". Le processus ne peut pas accéder au fichier "bin\Debug\MyProject.exe" car il est utilisé par un autre processus.
Googler l’erreur ne donne rien de plus qu’évident, c’est-à-dire que VS pense que le fichier est verrouillé. Et c’est définitivement Visual Studio lui-même qui verrouille le fichier, car lorsque je ferme le VS et le rouvre, le projet s’exécute correctement - du premier coup. Lorsque j'essaie de l'exécuter une seconde fois, j'obtiens l'erreur de verrouillage de fichier.
Fermer VS et rouvrir à chaque fois que je veux exécuter l’application n’est pas une solution viable! Comment savoir ce qui verrouille le fichier et comment l'empêcher de se verrouiller?
EDIT: Une autre découverte intéressante: je n'ai même pas à exécuter l'application. Le simple fait de le compiler une fois provoque le verrouillage du fichier; Je ne peux pas compiler deux fois de suite!
Ce problème est spécifique à un projet de ma solution. Tous les autres projets fonctionnent bien et peuvent être exécutés autant de fois que je le souhaite. Ce n'est que ce projet qui se met sous clé.
Eh bien, j'ai résolu le problème moi-même - bien que je ne sache toujours pas pourquoi. J'ai décidé d'isoler le problème en supprimant tous les fichiers du projet, en les rajoutant et en déterminant de quelle manière le fichier était la source de mon problème. Alors, un par un, j'ai réintroduit des fichiers dans le projet, compilé et nettoyé chaque étape du chemin ... jusqu'à ... j'ai ajouté le dernier ...
... et tout fonctionnait toujours bien.
J'ai fait une comparaison avec le contrôle de source de mon .csproj d'origine; pas de réelles différences. Et même lorsque j’ai essayé de revenir à la version précédente du .csproj, cela fonctionnait toujours.
Magie noire. Si cela fonctionne, il vaut parfois mieux ne pas demander pourquoi - il suffit de l'accepter et de passer à autre chose ...
EDIT: Le problème est récurrent et je pense l'avoir isolé lorsque le concepteur de formulaire ouvre un formulaire abstrait/générique au moment de la compilation.
Leçon apprise: Assurez-vous que le concepteur de formulaire de tout formulaire ou contrôle abstrait ou générique est fermé avant de compiler! Sinon, vous devez fermer VS et rouvrir!
J'ai trouvé une solution simple qui fonctionne pour moi. Ça va comme ça:
Lorsque le problème survient, il suffit de modifier la configuration du bâtiment en haut (si «Libération» est défini sur «Débogage» et vice-versa), de générer, puis de revenir à la configuration précédente et de générer à nouveau.
Je suppose que la modification de la configuration libère vcshost et devenv.
Voici ce que nous avons découvert ici: Dans la page des propriétés du projet, sous l’onglet Debug, décochez la case "Activer le processus d’hébergement de Visual Studio". Je ne suis pas sûr de savoir à quoi sert cette propriété, mais elle effectue le travail une fois que celle-ci n’a pas été vérifiée.
En fait, cochez la case "Activer le processus d’hébergement Visual Studio". Au moins pour VS2010 quand même. Et j'ai aussi:
si existe "$ (TargetPath) .locked" del "$ (TargetPath) .locked" s'il existe "$ (TargetPath)" s'il n'existe pas "$ (TargetPath) .locked" move "$ (TargetPath)" "$ (TargetPath) .locked "
dans les options de pré-construction. Ce problème me persiste depuis très longtemps et ce n’est que lorsque John W. a mentionné cette case à cocher que j’ai même remarqué qu’elle existait bien et qu’elle était déjà décochée.
Notez également que -app-vshost.exe s'exécute en arrière-plan, même en l'absence de débogage. C'est ce qui fait qu'il réussit à construire et à fonctionner à chaque fois, je suppose. Il ne courait pas avant. Et j'ai également essayé de nettoyer les dossiers de débogage et de publication et de changer le type de cible constamment et rien ne fonctionnait sauf comme décrit ci-dessus. Ma solution auparavant consistait simplement à attendre 5 minutes entre les versions, ce qui était extrêmement ennuyeux et fastidieux. Je n'ai vu aucun changement de comportement, qu'il s'agisse d'onglets ouverts ou de fenêtres XNA vs Windows ou de concepteurs ouverts. Ce problème se produisait dans les versions 32 bits ou 64 bits et importait peu si j'avais tué une application avec ALT-F4 ou avec le gestionnaire de tâches, ce qui, en théorie, ne permettrait pas à l'application de fermer ou de libérer des ressources. Au début, je pensais que c'était un problème de ramassage des ordures.
Un peu tard pour répondre, mais je résous cela en allant dans les propriétés du projet> onglet "Débogage"> décocher "Activer le processus d'hébergement Visual Studio".
VS2017 - Résolu en fermant toutes les instances de MSBuild.exe dans le gestionnaire de tâches Windows
J'ai résolu ce problème en supprimant le dossier bin\Debug et, éventuellement, en redémarrant VS
J'ai surmonté ce problème en renommant le fichier verrouillé (à l'aide de l'Explorateur Windows). Je n'ai pas été autorisé à supprimer le fichier, mais renommer le fichier verrouillé fonctionne!
J'ai eu le même problème sur mon application Xamarin dans Visual Studio et le problème a été résolu en débranchant mon appareil mobile de test. L'application était fermée et le débogueur arrêté, mais l'erreur persistait lors de la création ou de la reconstruction de la solution. Il ne s’est arrêté qu’après avoir débranché l’appareil car je devais recevoir un appel.
Il suffit de vérifier les références et de supprimer la référence automatique au projet.
Explication: Mon problème a commencé après la création d'un contrôle personnalisé, son glisser-déposer dans la palette de la boîte à outils et son utilisation dans les formulaires de conception. D'abord apparu un avertissement indiquant qu'il y avait une redondance entre le fichier source de contrôle personnalisé (.cs) et l'exécutable du projet (.exe). Lors de l’exécution/du débogage, l’erreur suivante est apparue: impossible d’accéder au fichier (.exe) car celui-ci est utilisé (et c’est vrai).
J'ai littéralement enlevé tout le code source concernant le contrôle personnalisé et le problème persiste jusqu'à ce que je vérifie les références et qu'il se réfère lui-même afin de pouvoir "obtenir" l'ancien contrôle personnalisé. J'ai enlevé la référence et fait !!
Exécutez cette commande à partir de la boîte de dialogue Exécuter:
net stop iisadmin /y
et alors
iisreset
a travaillé pour moi . vs 2003
Juste pour jeter mes 2 centimes. Mon problème a été résolu en ouvrant le Gestionnaire des tâches et en supprimant l'application. Il fonctionnait en arrière-plan sans indiquer son fonctionnement (aucun élément dans la barre des tâches, aucune interface utilisateur, rien), mais je ne suis pas sûr de savoir pourquoi cela s'est produit. Évidemment, le débogueur ne fonctionnait pas et je n'avais qu'une seule instance de VS ouverte à la fois. Cela me surprend que cela se produise encore dans ce VS 2017.
Je peux peut-être ajouter une étape de construction qui recherche l'application exécutant l'arrière-plan et la supprime avant de lancer la nouvelle.
Pour moi, c'était un service Windows installé et en cours d'exécution. Une fois que je l'ai arrêté, la construction a réussi.
Ce qui a fonctionné pour moi a été de redémarrer IIS
Dans mon cas, certains processus vstest étaient en cours d'exécution (avec différents noms mais tous contenant la chaîne vstest). Je devais les terminer dans taskmgr.
Comment votre application Web est-elle configurée? Est-ce qu'il fonctionne sous Cassini (le serveur Web du bac) ou IIS?
Cela ne devrait pas arriver normalement cependant. Je pense que ProcessExplorer peut vous dire quels fichiers un processus a bloqué. Si ce n'est pas le cas, explorez l'un des autres outils sysinternals.
Une chose à essayer avant même de télécharger l'un des outils SI est d'arrêter le serveur Web Cassini et de voir si cela libère le fichier.
j'ai eu ce même problème aussi. changer la configuration de débogage/libération n'a pas fait l'affaire. du moins pas sans construire entre les deux.
dans ma solution (winform), cela a été résolu en ouvrant le mainform de winform dans le concepteur. passage au code (F7). Fermez ensuite le code, fermez le concepteur du winform et reconstruisez tout (ctrl-shift-B). Cela a fonctionné pour moi.
semble être une sorte de poignée dans l’application Winform (qui exécute un arrière-plan), il avait toujours une poignée de fichier sur certaines des autres bibliothèques utilisées.
Pour ceux qui développent dans VS avec Docker, redémarrez le service Docker pour Windows et le problème sera résolu immédiatement.
Avant de redémarrer docker, j’ai essayé toutes les réponses mentionnées, je n’ai trouvé aucun processus msbuild.exe en cours d’exécution, j’ai également essayé de redémarrer VS sans succès, seul le redémarrage de docker a fonctionné.
Récemment rencontré ce problème lors de la tentative de construire une solution sur laquelle je travaille (pas seulement un projet winforms).
En plus de l'échec de build, j'ai remarqué que les projets de nettoyage échouaient silencieusement (la vérification du dossier bin indiquait que les fichiers n'avaient pas été réellement effacés) et la fermeture de Visual Studio ne mettait pas fin au processus devenv. crash. Le processus de récupération Windows redémarre ensuite Visual Studio.
Après quelques essais et erreurs, j’ai constaté que les problèmes ne m’arrivaient que lorsque j’ouvrais la solution à partir du menu "Récent" au démarrage de VS.
L’ouverture de la solution à partir de File >> Open >> Project/Solution s’est révélée efficace.
Actuellement, je ne sais pas pourquoi - je vais continuer à chercher, mais pour le moment, au moins, je peux travailler!
J'ai récemment rencontré le problème lors du déploiement sur Service Fabric. L'erreur implique qu'un "fichier" est en cours d'utilisation. Cependant, j'ai constaté que le port était utilisé par un autre IDE. En arrêtant un service en cours d’hébergement déjà hébergé sur le port, j’ai pu empêcher cette exception de se produire.
Quand j'ai fini le processus .Net Core Host, tout a bien fonctionné. Je n'ai pas eu besoin de fermer Visual Studio ou de changer quoi que ce soit d'autre.
Même erreur, résolue en mettant à jour les packages de support de Google Nuget
J'ai eu le même problème et je ne pouvais pas remédier en utilisant l'une des méthodes mentionnées dans les réponses précédentes. J'ai résolu le problème en supprimant toutes les instances de "SSIS Debug Hist (32 bits)" dans le gestionnaire de tâches et en fonctionnant désormais normalement.
J'ai eu deux instances de Visual Studio ouvert la même solution.
Une autre solution: lorsque les fichiers sont verrouillés, un processus de blocage est signalé (quelque chose comme "ServiceHub.Host.CLR.x64 (7764)") avec son identifiant entre parenthèses. Pour vous débarrasser du processus, ouvrez PowerShell (x + Win + I) et tapez: "Stop-Process -Id idNumber".