Débogage VisualStudio2010 - Le processus ne peut pas accéder au fichier ... car il est utilisé par un autre processus

Question

Je ne parviens pas à déboguer une application WinForms C# en utilisant la version publiée de Visual Studio 2010 Prof.

J'obtiens 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" à "bin \Debug\Arrowgrass Reports.exe". Le processus ne peut pas accéder au fichier 'bin \Debug\Arrowgrass Reports.exe" parce qu'il est utilisé par un autre processus.

J'ai essayé un script pré-build pour tenter de supprimer ce fichier, mais il 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 a-t-il un correctif ou une solution de contournement efficace ?

Answer 1

J'ai trouvé ce problème très facile à reproduire, et la solution pour moi est une variation de la réponse de Richard Fors. Si j'ai un UserControl ouvert dans le concepteur, que j'exécute le débogueur, puis que je modifie le UserControl, la reconstruction ultérieure échouera. Si je ferme le UserControl avant d'exécuter le débogueur, je n'obtiens jamais cette erreur. Je m'assure donc de fermer la fenêtre du concepteur avant d'appuyer sur F5.

Answer 2

En octobre 2012, j'ai toujours ce problème, donc le SP1 de VS 2010 n'a pas résolu le problème. Ce que j'ai fait, et qui a fonctionné de manière cohérente, a été 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

Answer 3

Vous pouvez essayer de tuer le processus vshost.exe :

taskkill /F /IM "Arrowgrass Reports.vshosts.exe"

Vous pourriez aussi avoir de la chance et simplement être en mesure de 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é-construction de votre projet :

if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"

Answer 4

La désactivation de la recherche Windows n'a rien arrangé pour moi. En revanche, la désactivation de l'antivirus l'a fait (notre antivirus est Symantec Endpoint Protection 11).

J'ai pu résoudre ce problème en modifiant les paramètres de débogage du projet afin de faire pointer le dossier de travail vers un chemin sur le lecteur C :, puis en excluant ce chemin des paramètres d'analyse de la protection automatique de l'antivirus.

J'espère que cela aidera quelqu'un.

Answer 5

J'ai posté cette réponse dans une question similaire mais je me suis dit que je devais aussi la dire ici :

D'accord... ça peut sembler assez fou.

J'ai ce problème dans VS2010 depuis deux ans. La solution de contournement mentionnée ici fonctionne pour moi, mais j'ai souvent oublié de fermer d'abord tous mes formulaires/contrôles d'utilisateur.

J'ai découvert que le simple fait d'aller voir les fichiers ouverts via :

Computer Management (compmgmt.msc)->Shared Folders->Open Files

va "libérer" le fichier verrouillé. Très étrange, mais ça marche pour moi !