Visual Studio «Impossible de copier»… pendant la construction

Je continue à avoir cette erreur lors de la construction de mon projet VS2012 C #

Error 41 Could not copy "obj\Debug\WeinGartner.WeinCad.exe" to "bin\Debug\WeinGartner.WeinCad.exe". Exceeded retry count of 10. Failed. Error 42 Unable to copy file "obj\Debug\WeinGartner.WeinCad.exe" to "bin\Debug\WeinGartner.WeinCad.exe". The process cannot access the file 'bin\Debug\WeinGartner.WeinCad.exe' because it is being used by another process. 

Maintenant, j’ai compris que tuer le processus

 Weingartner.WeinCad.vhost.exe 

ça marche (parfois) mais ça m’énerve. Un moyen d’empêcher que cela se produise?

Mes parameters de débogueur sont

entrer la description de l'image icientrer la description de l'image ici

J’ai rencontré des messages d’erreur similaires dans Visual Studio 2013.

La plupart du temps, j’ai constaté que cette situation s’était produite lorsqu’un processus de débogage avait été interrompu à cause d’une exception.

Lorsque clean + build n’a pas résolu ce problème pour moi, j’ai réussi en procédant comme suit:

  • Fermeture de Visual Studio
  • Supprimer les dossiers bin et obj et
  • Réouverture de Visual Studio.

Ce “bug” existe depuis Visual Studio 2003.

Enfin, j’ai également constaté que je peux souvent surmonter ce problème en renommant simplement le fichier exécutable puis en le supprimant.

Dans Visual Studio Premium 2013 (mise à jour 3), j’ai résolu ce problème avec une ligne pré-construction:

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

Cela supprime gracieusement tous les anciens fichiers PDB (le cas échéant), puis renomme tout ce qui rest avec une extension .old.pdb . Un effet secondaire intéressant est que si l’ancien PDB est toujours verrouillé, il ajoute simplement un autre élément .old au nom du fichier, et ils seront tous nettoyés la prochaine fois que vous redémarrez Visual Studio et effectuez une génération.

Par exemple, la session de construction / débogage 1 laisse MyProject.pdb verrouillé.
La prochaine fois que vous construirez:
MyProject.pdb -> MyProject.old.pdb

Ensuite, la session de génération / débogage 2 est démarrée et MyProject.pdb et MyProject.old.pdb sont toujours verrouillés:
MyProject.old.pdb -> MyProject.old.old.pdb
MyProject.pdb -> MyProject.old.pdb

Enfin, le redémarrage de Visual Studio et la réalisation d’une nouvelle version suppriment ces deux éléments et poursuivent le processus normalement.

C’est parce que vous avez fermé votre application, mais qu’elle fonctionne toujours en arrière-plan.

Solution temporaire:

  • Accédez au gestionnaire de tâches ( Ctrl + Alt + Esc ).
  • Allez dans l’onglet Processus et trouvez “YourProjectName.exe”.
  • Cochez “Afficher les processus de tous les utilisateurs” si vous ne trouvez pas votre processus.
  • Terminez le processus.

Solution permanente: vous devez fermer votre application en codant. Voici le code …

 System.Windows.Forms.Application.Exit(); 

Vous devez mettre ce code dans l’événement de clôture du formulaire sous toutes ses formes. Exemple:

 private void frm_menu_FormClosing(object sender, FormClosingEventArgs e) { System.Windows.Forms.Application.Exit(); } 

le fichier .vhost.exe est un processus de débogage, il semble donc que le processus en cours de débogage ne soit pas correctement fermé. Il y a des chances que vous ayez un bogue qui le maintienne en vie et qui n’arrête pas correctement le processus de débogage – il existe des options pour se détacher du processus lorsque vous cliquez sur “Arrêter le débogage”.

Mais c’est le problème – le fichier que vous essayez de copier est verrouillé (c’est-à-dire qu’il est toujours utilisé) par le système d’exploitation afin d’empêcher la copie. Assurez-vous que le fichier est gratuit et que vous pourrez le copier.

Je l’ai résolu en tuant IISExpress dans le gestionnaire de tâches

Vous devriez désactiver votre antivirus (surtout s’il s’agit d’un Avast) et réessayer. Ça m’a aidé. Le problème est que le débogueur / générateur crée le fichier .exe identifié comme une menace par Avast et donc supprimé juste avant qu’il puisse être exécuté par VS.

J’ai pu résoudre ce problème (VS 2010) en fournissant les actions de pré-construction suivantes;

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

Citation:

Une solution consiste à placer ceci dans la propriété de ligne de commande d’événement de pré-génération du projet> (dans l’onglet Événements de génération):

Extrait de code

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

Tuer le processus w3wp.exe (IIS) résoudra souvent ce problème.
Généralement, vous pouvez connaître le processus qui a le verrou sur le fichier en naviguant vers le dossier bin et en essayant de le supprimer. Le message d’erreur qui apparaîtra, dans le cas où un autre processus l’utilise, contiendra le nom du processus à supprimer.

Exception

Dans certains cas, dans Visual Studio, lorsque vous (Build || Rebuild) exécutez IISExpress, vous êtes confronté à cette exception:

Impossible de copier le fichier “obj \ Debug \ YourProjectName.dll” dans bin \ YourProjectName.dll “. Le processus ne peut pas accéder au fichier ‘bin \ YourProjectName.dll’ car il est utilisé par un autre processus

Solution

  1. Cliquez avec le bouton droit sur le projet Web à construire.
  2. Cliquez sur les propriétés.
  3. Sélectionnez l’onglet Créer des événements sur le côté gauche.
  4. Dans la ligne de commande des événements de pré-construction, collez ces 2 lignes:
 tasklist /fi "imagename eq iisexpress.exe" |find ":" > nul if errorlevel 1 taskkill /f /im "iisexpress.exe" 

Tu es bon 2 GO!

J’ai rencontré le même problème sur VS 2012 Version 11.0.60610.01 Update 3 sur Windows 8

Il n’y avait pas de fenêtres de concepteur ouvertes et le projet était une application console simple.

La suppression du processus vshost accédant au fichier ne fonctionne pas la plupart du temps car le processus n’accède pas au fichier.

La solution la plus simple qui fonctionne et prend le moins de temps consiste à supprimer le projet de la solution, à créer un autre projet dans la solution, puis à append l’original.

C’est un irritant et une perte de temps, mais c’est la moins chère de toutes les autres options que je connaisse.

J’espère que cela t’aides…

Je pense que je l’ai résolu en supprimant la coche pour Break all processes when one process breaks dans les options de débogage (première capture d’écran de l’op-> deuxième option).
Il a été construit / fonctionne bien pendant un moment depuis que je l’ai décoché.
J’utilise les contrôles MySql NET Connector et DevExpress dans mon projet. Peut-être l’un d’entre eux ne disposait-il pas de connexions, de liaisons, etc. à cause de l’activation de ce drapeau.

EDITED: certainement ça marche! Pas plus de «Impossible de copier le fichier» et plus d’erreurs de concepteur de formulaires.

Il semble que par changement, le nom de l’assembly d’un projet corrige le problème.

Donc au lieu de cela

entrer la description de l'image ici

Je le change à ceci

entrer la description de l'image ici

Notez que je viens de changer d’ Increment and Recall en Increment_Recall , je viens de supprimer les espaces. Cela fonctionne maintenant très bien pour moi.

Ajouter dans l’événement de pré-construction de votre projet masterkill / f / fi “pid gt 0” / im “YourProcess.vshost.exe”

Ma consortingbution de 10 cents.

J’ai toujours ce problème occasionnellement sur VS 2015 Update 2.

J’ai trouvé que le changement de cible de compilation résout le problème.

Essayez ceci: si vous êtes en mode DEBUG, passez à RELEASE et comstackz, puis revenez à DEBUG. Le problème est parti.

Stefano

Solution: Redémarrez le système d’exploitation, cela fonctionne toujours pour moi, car le processus vshost ne peut pas être interrompu de temps en temps.

Ce bogue existe également dans les versions de la série VS, y compris VS2013.

Vous pouvez vous référer au lien: http://connect.microsoft.com/VisualStudio/feedback/details/533411

Je ne peux pas vous donner une solution pour empêcher que cela se produise, mais vous pouvez au moins RENOMMER le fichier verrouillé (Windows Explorer ou fenêtre de commande classique), puis comstackr / comstackr. Pas besoin de redémarrer ou de redémarrer VS201x. Avec un peu d’expérience, vous pouvez append un script de pré-compilation pour supprimer les anciens fichiers ou les renommer, au cas où il y aurait un verrou.

Voir cette autre réponse . Fondamentalement, vous pouvez avoir des processus MSBuild.exe en cours d’exécution en arrière-plan en utilisant des fichiers de ressources. Si vous avez des tâches préalables ou postérieures à la génération qui provoquent le lancement d’un MSBuild via la ligne de commande, essayez d’append l’indicateur “/ nr: false” à cette commande. Mais encore une fois, voir la réponse précédente pour plus de détails.

La réponse de @Geoff ( https://stackoverflow.com/a/25251766/3739540 ) est bonne, mais elle renvoie le code d’erreur 1 sur la recompilation.

Voici ce qui a fonctionné pour moi (2> nul 1> nul à la fin + exit 0):

 (if exist "$(TargetDir)*old.pdb" del "$(TargetDir)*old.pdb") & (if exist "$(TargetDir)*.pdb" ren "$(TargetDir)*.pdb" *.old.pdb) 2>nul 1>nul (if exist "$(TargetDir)*old.dll" del "$(TargetDir)*old.dll") & (if exist "$(TargetDir)*.dll" ren "$(TargetDir)*.dll" *.old.dll) 2>nul 1>nul exit 0 

Si vous déboguez des modèles T4 , cela se produit tout le temps. Ma solution (avant que MS répare cela) serait juste de tuer ce processus:

Gestionnaire des tâches -> Utilisateur -> T4VSHostProcess.exe

Ce processus ne s’affiche que lorsque vous déboguez un modèle T4, pas lorsque vous en exécutez un.

  1. Ouvrir les propriétés du projet [menu> projet> propriétés]
  2. Choisissez l’onglet “debug”
  3. Décochez la case “Activer le processus d’hébergement de studio visuel”
  4. Lancer le débogage [F5]
  5. Vous recevrez un avertissement de sécurité, juste “ok”. Permet à l’application de fonctionner
  6. Arrêtez le débogage
  7. Cochez l’option “Activer le processus d’hébergement de studio visuel”, sous l’onglet de débogage,
  8. Maintenant, essayez de commencer le débogage, vous ne verrez plus d’erreur

[Travaille pour moi]

Suivez les étapes ci-dessous

  1. Ouvrir le gestionnaire de tâches (Ctrl + Alt + Suppr)
  2. Sous l’onglet Performances, sélectionnez sélectionnez < ProjectNameOfYours.exe >.
  3. Cliquez sur Terminer le processus.
  4. Maintenant, construisez la solution.

Au dessus des étapes résolues erreur définitivement 🙂

Si aucune des réponses ne fonctionne, essayez cette simple vérification. Recherchez tout MSbuild.exe en cours d’exécution et en maintenant votre EXE de projet. Kill MSBuild.exe et vous devriez être prêt à partir.

Je finalement comment le réparer. Pourquoi nous ne pouvons pas continuer le débogage après le premier débogage, car le premier exe de débogage est toujours en cours d’exécution. Ainsi, après le premier débogage, vous devez vous rendre dans le Gestionnaire des tâches -> Onglet Processus -> [votre nom de projet exe] pour mettre fin au processus exe.

ça marche pour moi 🙂

Cette question était le premier résultat lors de la recherche de l’erreur suivante:

Impossible de copier le fichier “…” car il n’a pas été trouvé.

lors de la création dans Visual Studio 2013 (mise à jour 3).

Solution: Désinstallation de “Productivity Power Tools” dans Visual Studio 2013.

https://connect.microsoft.com/VisualStudio/feedback/details/533411

Dans mon cas, il s’agissait de Resharper Unit Tests runner (plus les tests NUnit, jamais eu un tel problème avec MsTests). Après avoir tué le processus, a pu reconstruire le processus, sans redémarrer le système d’exploitation ou VS2013

Je n’avais pas réalisé que mon débogueur était toujours connecté et essayais de construire dans la même instance de Visual Studio. Une fois que j’ai arrêté le débogueur, j’ai pu construire.

Tuer le processus vstest.executionengine.exe résout ce problème dans 90% des cas. Si cela ne fonctionne pas, alors le fait de tuer QTAgent32.exe , puis de supprimer les dossiers / bin et / obj du projet en question fonctionne.

C’est la partie la plus irritante de ma journée de travail. 🙂

Pour moi, ce sont les antivirus Avast qui ne permettent pas à Visual Studio d’écrire / lire / exécuter des fichiers. J’ai donc dû append le dossier Visual studio 2010/2012 à la liste d’exclusion d’antivirus. Et juste après ce baam … ça marche.

Assurez-vous de fermer toutes les instances wcfSvcHost et réessayez. Cela a fonctionné pour moi!