Débogage Visual Studio 2010 - Le processus ne peut pas accéder au fichier ... car il est utilisé par un autre processus
Je ne parviens pas à déboguer une application WinForms C # à l'aide de la version finale de Visual Studio 2010 Prof.
Je reçois le message d'erreur suivant après la deuxième exécution du débogage.
Erreur 9 Impossible de copier le fichier "obj\x86\Debug\Arrowgrass Reports.exe" dans "bin\Debug\Arrowgrass Reports.exe". Le processus ne peut pas accéder au fichier 'bin\Debug\Arrowgrass Reports.exe' car il est utilisé par un autre processus.
J'ai essayé un script de pré-génération pour tenter de supprimer ce fichier, mais celui-ci est verrouillé par Visual Studio.
Il y a quelques références à cela sur le net, donc c'est un problème connu. Quelqu'un at-il un correctif ou une solution de contournement efficace?
J'ai trouvé ce problème très facile à reproduire et la solution pour moi est une variante de la réponse de Richard Fors. Si un UserControl est ouvert dans le concepteur, exécutez le débogueur, puis modifiez le contrôle UserControl, la reconstruction ultérieure échouera. Si je ferme UserControl avant d'exécuter le débogueur, je ne reçois jamais cette erreur. Je m'assure donc de fermer la fenêtre du concepteur avant d'appuyer sur F5.
Depuis octobre 2012, le problème persiste, ce qui fait que le VS 2010 SP1 n'a pas résolu le problème. Ce que j'ai fait et travaillé de manière cohérente, c’est de désactiver le processus d’hébergement dans les projets.
Pour désactiver le processus d'hébergement:
. Open a project in Visual Studio.
. On the Project menu, click Properties.
. Click the Debug tab.
. Clear the Enable the Visual Studio hosting process check box.
Source: http://msdn.Microsoft.com/en-us/library/ms185330(v=vs.100).aspx
Vous pouvez essayer de tuer le processus vshost.exe:
taskkill /F /IM "Arrowgrass Reports.vshosts.exe"
Vous pourriez également avoir de la chance et pouvoir simplement déplacer le fichier en question. Le déplacement du fichier peut être effectué en ajoutant les lignes de code suivantes à l'événement de pré-génération de votre projet:
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
Désactiver la recherche Windows ne m'a pas résolu. Cependant, l'antivirus a été désactivé (notre antivirus est Symantec Endpoint Protection 11).
En tant que tel, j'ai pu résoudre ce problème moi-même en modifiant les paramètres de débogage dans le projet afin de pointer le dossier de travail sur un chemin du lecteur C:, puis en excluant ce chemin des paramètres d'analyse à protection automatique antivirus.
J'espère que ça aidera quelqu'un.
J'ai posté cette réponse dans une question similaire mais je me suis dit que je le dirais aussi ici:
Bon ... ça peut paraître assez fou.
J'ai eu ce problème dans VS2010 pour les deux dernières années. La solution de contournement mentionnée ici fonctionne pour moi, mais souvent, j'ai oublié de fermer tous mes formulaires/contrôles utilisateur en premier.
J'ai découvert que simplement aller voir les fichiers ouverts via:
Computer Management (compmgmt.msc)->Shared Folders->Open Files
va "libérer" le fichier qui est verrouillé. Très étrange, mais ça marche pour moi!
Dans mon cas, j'ai sélectionné Propriétés du projet -> Onglet Sécurité -> Décocher les paramètres de sécurité en un clic (si cette case est cochée). Cela a fonctionné pour moi. Dans mon projet, cette erreur était indiquée pour une DLL C++ utilisée dans mon projet C #.
Recherchez le processus spécifié dans le Gestionnaire des tâches et mettez fin au processus de manière explicite. Cette solution a fonctionné pour moi.
La fermeture a récemment changé Contrôles de l'utilisateur a résolu le problème dans mon scénario. J'espère que cela aidera quelqu'un là-bas.
La condition décrite peut également être provoquée par le comportement fautif DLL ou EXE se référençant lui-même; Dans ce cas, le test de Process Explorer décrit précédemment ne renvoie jamais de correspondance (par exemple, il n'est pas en cours d'exécution). Cette situation imprévue semble avoir été provoquée par une séquence d'opérations dans VS2010 (et probablement dans toutes les versions précédentes), ce qui ajoute insidieusement la référence en coulisse. La cause spécifique de cela n'a pas été recherchée (ni résolue à ma connaissance). Pour vérifier et résoudre cette erreur, assurez-vous simplement que le fichier en cause DLL ou EXE n'est pas répertorié comme une référence à lui-même.
Je ne peux pas écrire dans un commentaire, car pas à 50 points, mais pour moi j’ai exclu mon dossier de projet dans ESET Enpoint Security version 5. On dirait que certains fichiers ont été bloqués/bloqués. Mon erreur ne précisait pas quel fichier exe ou quel fichier était utilisé, il a donc fallu beaucoup de temps pour en arriver à ce que JoeC avait dit à propos de Antivirus et l'avoir essayé. Semble fonctionner maintenant (Visual Studio 2010 SP1)
J'ai rencontré ce problème lors du développement des services Windows. J'ai découvert que cela se produit lorsque le service est en cours d'exécution. Ainsi, il vous suffit d’arrêter le service (à partir de la console services.msc) et vous êtes prêt à partir!
J'espère que cela aide .. Tidjani.
Vous avez l'erreur ("Le processus ne peut pas accéder au fichier… car il est utilisé par un autre processus") lorsque j'ai modifié la solution (Visual Studio 2010 C # Express avec SP1) à partir de deux gros fichiers (10 fichiers sources, environ 500 lignes par fichier) projets avec un référençant l’autre, à beaucoup (6) de petits projets avec beaucoup de projets référençant d’autres projets.
Les références concernaient les fichiers dll et exe (leurs versions Debug), PAS les projets alors que ceux-ci se trouvaient dans la même solution.
J'ai ensuite appris que les références devaient être des projets, pas des fichiers, pour que F12 fonctionne correctement. J'ai donc modifié les références. Cela a permis à F12 de fonctionner (accès au fichier source plutôt qu’à une description de l’interface générée automatiquement) et, en même temps, l’erreur "impossible d’accéder au fichier" au cours de la construction a disparu.
J'ai seulement l'erreur "ne peut pas accéder au fichier" quand je fais des builds Release. Les références concernaient les versions Debug de exe/dll. Je soupçonne que ce mélange est ce qui déclenche le bogue dans VS.
Supprimez le fichier obj. Arrêtez votre service et redémarrez à nouveau.
Pour moi, la solution a été de changer le projet de démarrage en une dll (le problème ne se produit qu'en mode débogage lorsqu’une application est utilisée comme projet de démarrage). Si votre solution contient plusieurs projets (et elle contiendra une .dll, sinon vous n'obtiendrez pas le problème), passez à cette .dll, pas de .vshost.exe, pas de problème.
Tuer .vshost.exe ne fonctionnait pas non plus pour moi, car immédiatement après avoir recommencé, il avait verrouillé le fichier .dll.
Assurez-vous également de la propreté de vos références, en particulier dans les projets plus complexes, et préférez également les références de projet aux références d'assemblage, etc. Je suppose que les mauvaises références (circulaires et similaires) sont vouées à causer des problèmes, du moins l’ai-je lu.
Arrêtez le service IIS et essayez de le reconstruire ou, si vous pouvez vous permettre de redémarrer votre ordinateur, essayez-le. Travaillé pour moi dans les deux sens.
À votre santé
Essayez de supprimer le fichier .exe du dossier de débogage ou de publication (quel que soit votre travail) Windows vous demandera que le processus X l'ouvre et vous ne pouvez plus le supprimer. processus de la tâche X
La meilleure solution pour moi était de déplacer mes fichiers de projet hors de Mes documents - qui se trouve sur un serveur géré par le service informatique - et de les localiser localement sur mon lecteur C. Fonctionne également: décochez la case "Activer le processus d’hébergement Visual Studio", comme indiqué par d’autres personnes.
J'ai eu cette erreur lorsque le projet est sur un partage distant (par exemple, si votre env. $:: Homepath est redirigé de manière utile par votre service informatique vers un partage réseau). Assurez-vous que votre projet réside sur un lecteur local.
Je pense que je viens de trouver le coupable et la solution.
Allez aux services et arrêtez et désactivez le service "Windows Search".
Cela a résolu le problème pour moi maintenant.
L'ajout de ce qui suit à l'événement de pré-génération de la DLL partagée a fonctionné pour moi:
if exist "$(TargetPath).locked*" del "$(TargetPath).locked*"
set exitprebuildfor$(ProjectName)=
for /l %%a in (1,1,10) do (
if defined exitprebuildfor$(ProjectName) goto :ok
if not exist "$(TargetPath).locked%%a" if exist "$(TargetPath)" move "$(TargetPath)" "$(TargetPath).locked%%a" & set exitprebuildfor$(ProjectName)=1)
:ok
set exitprebuildfor$(ProjectName)=
Il est basé sur la solution donnée ici mais au lieu de simplement renommer la DLL en .locked, il essaie de le renommer. En utilisant 10, je rencontre généralement le problème une fois par jour, mais la valeur ant peut être utilisée.
On dirait que ce problème a (enfin!) Été résolu dans le VS2010 SP1
Mon problème était que Outlook 2010 (Outlook.exe) utilisait le même port que mon projet ASP.NET MVC avec IIS express.
Solution: fermez Outlook.exe, exécutez votre solution et ouvrez Outlook à nouveau (afin qu'il utilise un autre port).
J'espère que cela aidera quelqu'un, car j'ai reçu le même message d'erreur que celui décrit dans cette rubrique.
Supprimez votre dossier Bin et lancez l'application . Cela a fonctionné pour moi. :)
Essayez de désinstaller Windows Live SYNC. Est-ce que ça arrive encore?
Si vous travaillez sur un projet C # qui utilise la référence de DLL C, vous pouvez éliminer l'erreur en cochant la case Autoriser le code non sécurisé. Je sais que je n'ai pas utilisé de pointeurs dans mon projet C #, mais j'utilisais un opérateur au niveau des bits en C #. Peut-être que ces caractéristiques en forme de C le transforment en code "non sécurisé".
Pour projet Windows
Le processus d'hébergement Visual Studio peut contenir le pointeur de fichier exécutable. Pour arrêter l'instance de l'hôte, ouvrez le Project properties puis accédez à l'onglet Debug. Désélectionnez maintenant l'option Enable the Visual Studio hosting Process, puis cochez à nouveau la case pour déboguer.
Pour projet web
Le IIS peut contenir le pointeur de fichier. Le redémarrage de IIS peut résoudre le problème.
Ce qui a fonctionné pour moi a été de supprimer le statut "lecture seule" du dossier bin. Une fois que j'ai fait cela, cela a fonctionné depuis.
Désactivez simplement l'hébergement Visual Studio dans le débogage, exécutez le projet, relancez-le et exécutez le projet.
Ouvrez un projet dans Visual Studio.
. Dans le menu Projet, cliquez sur Propriétés.
. Cliquez sur l'onglet Débogage.
. Décochez la case Activer le processus d'hébergement Visual Studio.
Mon problème a commencé après la création d'un contrôle personnalisé et le glisser-déposer dans la palette de la boîte à outils pour l'utiliser 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).
Un littéralement enlevé tout le code source concernant le contrôle personnalisé et le dernier problème ne s'est jamais arrêté, 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 !!
Donc: il suffit de vérifier les références et de supprimer la référence automatique au projet.
Faites simplement une copie de l'ensemble du projet et exécutez le projet à partir de la nouvelle copie ... tout fonctionnera correctement ... Mais vous devrez mettre fin au processus de débogage pour pouvoir supprimer l'ancien projet.