Visual Studio «Impossible de copier»… pendant la génération

347

Je continue à recevoir 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

fonctionne (parfois), mais cela m'énerve. Est-il possible d'arrêter cela?

Mes paramètres de débogueur sont

entrez la description de l'image ici entrez la description de l'image ici

bradgonesurfing
la source
Pour moi, cela a été causé par un .exe lancé manuellement dans le répertoire Release. Le problème était que VS ne peut pas copier sur un exécutable toujours en cours d'exécution. J'essaierai de le corriger en nettoyant correctement les ressources afin que le programme ne reste pas suspendu après le bouton de fermeture de la fenêtre.
lahjaton_j
Il y a un bon résumé de ce problème avec les étapes typiques à résoudre dans cette question
LightCC
Cela se produisait pour moi car Windows Defender a décidé qu'il n'aimait plus le .exe du projet VS2019 sur lequel je travaille. J'y travaille depuis des semaines sans problème, mais aujourd'hui, devinez qu'une nouvelle mise à jour ne l'aimait pas. J'ai dû exclure mes dossiers source. Arrêté de se produire.
IronRod

Réponses:

401

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

Surtout, j'ai constaté que cette situation s'est produite lorsqu'un processus de débogage a été interrompu en raison 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
  • Suppression de la binet des objdossiers, et
  • Réouverture de Visual Studio.

Ce «bogue» 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.

Gérard
la source
8
Même chose ici, VS2013. Quitter, supprimer les artefacts de build, redémarrer -> tout va bien.
cacau
49
j'ai le même problème, mais après le redémarrage de VS, j'obtiens une version et les fichiers sont à nouveau verrouillés ..
Sonic Soul
54
Ce n'est pas une solution, au mieux une solution partielle. Je ne veux pas redémarrer VS toutes les 10 minutes. Le nettoyage de la solution fonctionne pour moi, mais le nettoyer toutes les 10 minutes n'est pas non plus une solution.
Legends
7
D'après mon expérience, VS2013 fait cela au moins 10 fois par jour pour moi, quelle que soit la machine sur laquelle je développe. C'est comme si le bug s'était aggravé. Just sayin '
AR
28
bug existe toujours dans VS 2019.
Akash KC
107

Dans Visual Studio Premium 2013 (mise à jour 3), j'ai résolu ce problème avec une doublure 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 (si cela est possible), puis renomme tout ce qui reste avec une .old.pdbextension. Un effet secondaire agréable est que si l'ancien PDB est toujours verrouillé, il ajoute simplement une autre pièce .old au nom de fichier, et ils seront tous nettoyés la prochaine fois que vous redémarrerez Visual Studio et effectuerez une génération.

Par exemple, la session de génération / débogage 1 reste MyProject.pdbverrouillée.
La prochaine fois que vous construirez:
MyProject.pdb->MyProject.old.pdb

Ensuite, la session build / debug 2 est démarré, et les deux MyProject.pdb et MyProject.old.pdbsont toujours verrouillé:
MyProject.old.pdb-> MyProject.old.old.pdb
MyProject.pdb->MyProject.old.pdb

Enfin, le redémarrage de Visual Studio et la création d'une nouvelle version se débarrasseront de ces deux éléments et poursuivront le processus comme d'habitude.

Geoff
la source
5
La même chose dans VS2010, VS 2012
Boogier
7
Merci, a parfaitement fonctionné pour moi en modifiant votre exemple pour utiliser des fichiers exe à la place. Je pense que cela pourrait également être un bug dans le dernier VS 2015 CTP.
Johny Skovdal
Heureux que cela ait aidé - j'ai toujours ma commande de pré-construction configurée, et cela fonctionne suffisamment bien pour que j'oublie qu'elle était là!
Geoff
3
Je déteste devoir faire ça en principal, mais ça marche, alors voilà! :) Merci d'avoir partagé cette perle, Geoff!
kayleeFrye_onDeck
1
Dernière (2018-03-11) Visual Studio 2017 v15.6.1: toujours un problème. Débogage, exception, assemblys dans le répertoire cible verrouillés. La solution ci-dessus avec * .pdb changé en * .dll s'applique toujours.
Michiel de Wolde
71

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

Solution temporaire:

  • Accédez au Gestionnaire des tâches ( Ctrl+ Alt+ Esc).
  • Accédez à l'onglet Processus et recherchez «YourProjectName.exe».
  • Cochez "Afficher les processus de tous les utilisateurs" si vous ne trouvez pas votre processus.
  • Terminez-le.

Solution permanente: vous devez fermer votre application via le codage. Voici le code ...

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

Vous devez mettre ce code dans l'événement de fermeture du formulaire dans tous les formulaires. Exemple:

private void frm_menu_FormClosing(object sender, FormClosingEventArgs e)
{
    System.Windows.Forms.Application.Exit();
}
Rushi Daxini
la source
1
C'était exactement ça. Visual Studio était tombé en panne et IIS Express fonctionnait toujours (dans mon cas). Tout ce que j'avais à faire était d'ouvrir la barre des tâches et de cliquer avec le bouton droit sur l'icône IIS Express et de quitter. Je vous remercie.
the-nick-wilson
Cela a fonctionné pour moi; Je n'ai pas pu supprimer les dossiers obj et bin car un autre processus les utilisait. Heureusement, Windows 10 a en fait dit son nom; une fois qu'il a été fermé dans le Gestionnaire des tâches, les problèmes ont disparu
Novastorm
25

le .vhost.exe est un processus de débogage, il semble donc que le processus en cours de débogage ne s'est pas fermé correctement. Il y a des chances que vous ayez un bogue qui le maintienne en vie et n'arrêtez pas le processus de débogage correctement - il existe des options pour se détacher du processus lorsque vous cliquez sur `` arrêter le débogage '' au lieu de tuer le débogueur, alors peut-être que vous avez cet ensemble.

Mais c'est le problème - le fichier que vous essayez de copier est verrouillé (c'est-à-dire toujours utilisé) par le système d'exploitation, ce qui empêche la copie. Assurez-vous que le fichier est gratuit et que vous pourrez le copier.

gbjbaanb
la source
J'ai ajouté mes options de débogueur aux questions. Je suis presque sûr que cela devrait tuer le processus, mais je ne comprends peut-être pas certaines options.
bradgonesurfing
Dans Visual Studio 2019, je reçois un message similaire, bien qu'il mentionne maintenant le processus dans une partie de la sortie (pas tous). C'est testhost.x86.exe que j'ai dû tuer via Task Manager. Après cela, il a semblé cesser de détecter l'un des processus de test.
Andez
23

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

pat capozzi
la source
20

Vous devez désactiver votre antivirus (en particulier 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 ne puisse être exécuté par VS.

Pitrs
la source
Bonne prise. Je déteste toujours Avast.
stackunderflow
Avast était aussi le problème pour moi. La désactivation du bouclier du système de fichiers était la réponse. J'ai essayé d'ajouter mon dossier Visual Studio \ Projects aux exclusions mais cela n'a pas fonctionné.
KeithB
1
J'ai le même problème avec la protection Symantec Endpoint. Quelqu'un dans le département informatique a augmenté le niveau de sécurité assez haut :-) Merci Pitrs.
ssimm
J'ajouterai que vous pouvez créer une exception pour le répertoire obj \ Debug pour une utilisation pratique, au lieu de désactiver l'AV ou l'un de ses outils de protection.
A. Kali
Merci! J'ai trouvé que c'était un MalwareBytes bloquant mon fichier .exe.
NL3294
15

J'ai pu résoudre ce problème (VS 2010) en fournissant l'action de pré-construction suivante;

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

if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
Nair
la source
1
@luckyluke, Dans les propriétés de votre projet, il y a une section où vous pouvez ajouter un script de pré-construction. Copiez et collez le script ci-dessus dans la zone désignée et reconstruisez le projet / exécutez votre application
Nair
13

Citation:

Une solution de contournement 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"
Zheng Qiang
la source
8

Exception

Dans certains cas, dans Visual Studio, lorsque vous (Build || Reconstruisez) en plus d' exécuter 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. Faites un clic droit sur le projet Web qui doit être construit.
  2. Cliquez sur 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é-génération, collez ces 2 lignes:
tasklist /fi "imagename eq iisexpress.exe" |find ":" > nul
if errorlevel 1 taskkill /f /im "iisexpress.exe"

Vous êtes bon 2 GO!

Xaimaran
la source
6

Il semble qu'en modifiant le nom de l'assembly d'un projet, le problème soit résolu.

Donc au lieu de ça

entrez la description de l'image ici

Je change ça

entrez la description de l'image ici

Notez que je viens changé de Increment and Recallà Increment_Recall, je viens enlever les espaces. Cela fonctionne maintenant très bien pour moi.

Cary Bondoc
la source
Super c'est résolu mon problème. Merci !!
Kiran Joshi
6

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 accédant au 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 qui doit être tué.

Ogglas
la source
4

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 simple application console.

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 de contournement 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 à rajouter 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...

Ashwin J
la source
Tout ce que vous avez à faire est de tout reconstruire et tout va bien pour 10 autres essais. Pas vraiment un inconvénient.
Scott Shaw-Smith
@Scott Shaw-Smith ne fonctionne pas pour moi. Et d'après certains des autres commentaires que j'ai vus, cela ne fonctionne pas non plus pour les autres. Dans mon cas, la désinstallation d'Avast l'a corrigé.
user316117
4

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

EDITÉ: ça marche vraiment! Plus de «Impossible de copier le fichier» et plus d'erreurs du concepteur de formulaires.

Villa Ivan Ferrer
la source
1
Aucune des autres solutions n'a fonctionné pour moi. C'est le seul. J'utilise Visual Studio 2017 13.2
xleon
1
Je viens de le tester dans VS2019, cela ne fonctionne pas pour moi
0xBADF00D
4

Ajoutez un événement de pré-génération de votre projet principal taskkill / f / fi "pid gt 0" / im "YourProcess.vshost.exe"

sofsntp
la source
Je n'aime pas vraiment résoudre le problème de cette façon, mais cela a fonctionné!
Petter T
J'ai trouvé cela la solution de travail la plus simple pour le problème.
décharge le
4

Ma contribution 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 dans DEBUG, passez à RELEASE et build, puis revenez à DEBUG. Le problème a disparu.

Stefano

Stefano.net
la source
Ouais! C'est ça. Ceci est une solution simple à ce problème ennuyeux! Totalement travaillé pour moi. Facile et rapide! Merci beaucoup.
Meister Schnitzel,
1
Ça marche pour moi! Astuce: avec le débogage désactivé >> Options >> Débogage >> Général >> "Utiliser le mode de compatibilité géré" la solution de contournement n'est pas nécessaire!
leon22
4

Suivez les étapes ci-dessous

  1. Ouvrez le Gestionnaire des tâches (Ctrl + Alt + Suppr)
  2. Sous l' onglet Performances, sélectionnez < ProjectNameOfYours.exe >.
  3. Cliquez sur Terminer le processus.
  4. Maintenant, créez une solution.

Les étapes ci-dessus ont résolu l'erreur définitivement :)

Akshay Bagi
la source
4

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

Gentilhomme
la source
2

Je ne peux pas donner de solution pour empêcher cela, mais vous pouvez au moins RENOMMER le fichier verrouillé (explorateur Windows ou fenêtre de commande classique), puis compiler / construire. Pas besoin de redémarrer ou de redémarrer VS201x. Avec une certaine expérience, vous pouvez ajouter un script de pré-construction pour supprimer les anciens fichiers ou renommer puis à l'écart en cas de verrouillage.

hopperpl
la source
2

Voir cette autre réponse . Fondamentalement, vous pourriez avoir des processus MSBuild.exe en cours d'exécution dans les fichiers de ressources consommant en arrière-plan. Si vous avez des tâches de pré ou post-génération qui provoquent le lancement d'un MSBuild via la ligne de commande, essayez d'ajouter l'indicateur "/ nr: false" à cette commande. Mais encore une fois, voir la réponse précédente pour des détails plus spécifiques.

Josh Pavoncello
la source
Snap, j'ai le même problème dans VS2015 update 2 - MSBuild, le processus exe doit être tué dans TaskManager avant de pouvoir reconstruire.
Nick Wright
Le lien de l'article dans la réponse de Josh ci-dessus suggère d'utiliser une variable d'environnement système pour désactiver la réutilisation des nœuds dans Visual Studio et le processus MSBuild (MSBUILDDISABLENODEREUSE = 1) - cela a fonctionné pour moi.
Nick Wright
2

J'ai enfin 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 aller dans le Gestionnaire des tâches -> onglet Processus -> [votre nom de projet exe] terminer le processus exe.

ça marche pour moi :)

chevhfghfghfgh
la source
Wow, merci mec, exactement mon problème. Comme il me demande le mot de passe de l'utilisateur lors de l'exécution de EXE, la première fois, il ne s'est pas déclenché. Lorsque j'essaie de supprimer cette application dans la liste des processus, puis de la déboguer à nouveau, cela a fonctionné parfaitement.
Chandraprakash
2

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

Voici ce qui a fonctionné pour moi (2> nul 1> nul à la fin + sortie 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
Michael Ribbons
la source
2

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

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

Ce processus n'apparaît que lorsque vous déboguez un modèle T4, pas lorsque vous en exécutez un.

Pompair
la source
2

Voici un script pour vous débarrasser définitivement de ce problème:

REM   This script is invoked before compiling an assembly, and if the target file exist, it moves it to a temporary location
REM   The file-move works even if the existing assembly file is currently locked-by/in-use-in any process.
REM   This way we can be sure that the compilation won't end up claiming the assembly cannot be erased!

echo PreBuildEvents 
echo  $(TargetPath) is %1
echo  $(TargetFileName) is %2 
echo  $(TargetDir) is %3   
echo  $(TargetName) is %4

set dir=C:\temp\LockedAssemblies

if not exist %dir% (mkdir %dir%)

REM   delete all assemblies moved not really locked by a process
del "%dir%\*" /q

REM   assembly file (.exe / .dll) - .pdb file and eventually .xml file (documentation) are concerned
REM   use %random% to let coexists several process that hold several versions of locked assemblies
if exist "%1"  move "%1" "%dir%\%2.locked.%random%"
if exist "%3%4.pdb" move "%3%4.pdb" "%dir%\%4.pdb.locked%random%"
if exist "%3%4.xml.locked" del "%dir%\%4.xml.locked%random%"

REM Code with Macros
REM   if exist "$(TargetPath)"  move "$(TargetPath)" "C:\temp\LockedAssemblies\$(TargetFileName).locked.%random%"
REM   if exist "$(TargetDir)$(TargetName).pdb" move "C:\temp\LockedAssemblies\$(TargetName).pdb" "$(TargetDir)$(TargetName).pdb.locked%random%"
REM   if exist "$(TargetDir)$(TargetName).xml.locked" del "C:\temp\LockedAssemblies\$(TargetName).xml.locked%random%"

REM PreBuildEvent code
REM   $(SolutionDir)\BuildProcess\PreBuildEvents.bat  "$(TargetPath)"  "$(TargetFileName)"  "$(TargetDir)"  "$(TargetName)"

REM References:
REM   http://www.hanselman.com/blog/ManagingMultipleConfigurationFileEnvironmentsWithPreBuildEvents.aspx
REM   http://stackoverflow.com/a/2738456/27194
REM   http://stackoverflow.com/a/35800302/27194

Le script doit être appelé à partir de chaque événement de pré-construction du projet VS.

$(SolutionDir)\BuildProcess\PreBuildEvents.bat  "$(TargetPath)"  "$(TargetFileName)"  "$(TargetDir)"  "$(TargetName)"

entrez la description de l'image ici

Patrick de l'équipe NDepend
la source
2
  1. Ouvrir les propriétés du projet [menu> projet> propriétés]
  2. Choisissez l'onglet "debug"
  3. Décochez "Activer le processus d'hébergement de Visual Studio"
  4. Démarrer le débogage [F5]
  5. Vous recevrez un avertissement de sécurité, juste "ok". Permet à l'application de s'exécuter
  6. Arrêtez le débogage.
  7. Cochez l'option "Activer le processus d'hébergement de Visual Studio", sous l'onglet de débogage,
  8. Maintenant, essayez de démarrer le débogage, vous ne verrez plus d'erreur

[Travaille pour moi]

Novpiar Effendi
la source
Pourquoi était-ce à -2? Cela a également fonctionné pour moi. Ça n'a aucun sens mais bon, si ça marche, ça marche.
Wakka02
Est-ce une solution permanente? c'est-à-dire que vous devez faire ces 8 étapes à chaque fois?
Arthur Swails
vs17 n'a pas l'option de processus d'hébergement
John Demetriou
1

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

Impossible de copier le fichier "..." car il est introuvable.

lors de la génération dans Visual Studio 2013 (mise à jour 3).

Solution: désinstallation des «outils électriques de productivité» dans Visual Studio 2013.

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

despuestambien
la source
Obtention de cette erreur plusieurs fois lors de la génération d'un projet hérité de TFS. Je pensais que c'était ça! Recherche dans les programmes installés et les compléments. Impossible de trouver cette application d'outils électriques. Où cela se cacherait-il?
Taersious
1

Dans mon cas, c'était le coureur Resharper Unit Tests (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

Uriil
la source
Oui, cherchezJetBrains.Resharper.TaskRunner.*
Dunc
1

Je ne savais pas que j'avais toujours mon débogueur attaché 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 le construire.

Valamas
la source
1

Tuer le (s) processus vstest.executionengine.exe résout ce problème 90% du temps pour moi. Si cela ne fonctionne pas, tuez également QTAgent32.exe la suppression de et la suppression des dossiers / bin et / obj pour le projet en question fonctionnent également.

C'est la partie la plus irritante de ma journée de travail. :)

dgundersen
la source
1

Pour moi, c'était l'antivirus Avast qui ne permet pas à Visual Studio d'écrire / lire / exécuter un fichier. J'ai donc dû ajouter le dossier Visual studio 2010/2012 à la liste d'exclusion des antivirus. Et juste après ce baam ... ça marche.

Alex
la source
1

Assurez-vous que vous fermez toutes les instances wcfSvcHost et réessayez. Ça a marché pour moi!

Ocelot
la source