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

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

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.

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.

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();
}

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.

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

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.

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"

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"

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!

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

Donc au lieu de ça

Je change ça

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

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é.

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...

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.

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

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

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 :)

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.

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.

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.

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 :)

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

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.

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)"

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]

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

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

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.

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. :)

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.

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