c# - échec - visual studio generate exe




Visual Studio "Impossible de copier"... lors de la génération (20)

Je continue d'obtenir 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

travaille (parfois) mais cela m'énerve. Un moyen d'empêcher cela de se produire?

Mes paramètres de débogueur sont


Exception

Dans certains cas dans Visual Studio lorsque vous (Build || Reconstruire) en plus de l' exécution de IISExpress vous avez rencontré 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 Construire les événements sur le côté gauche.
  4. Dans la ligne de commande des événements de pré-construction, collez ces deux lignes:
tasklist /fi "imagename eq iisexpress.exe" |find ":" > nul
if errorlevel 1 taskkill /f /im "iisexpress.exe"

Vous êtes bon 2 GO!


  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 studio visuel"
  4. Commencer 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 Visual Studio", sous l'onglet de débogage,
  8. Maintenant, essayez de déboguer, vous ne verrez plus l'erreur

[Travaille pour moi]


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


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

Solution temporaire:

  • Allez dans le Gestionnaire des tâches ( Ctrl + Alt + Echap ).
  • Allez à l'onglet Processus et trouvez "YourProjectName.exe".
  • Terminez le processus.

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

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

Vous devez placer ce code dans l'événement de fermeture du formulaire sous toute forme. Exemple:

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

Citation:

Une solution de contournement consiste à placer cela dans la propriété de ligne de commande de l'événement Pre-build 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"

Dans Visual Studio Premium 2013 (mise à jour 3), j'ai résolu cela avec un pré-build un doublure:

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

Cela supprime avec élégance tous les anciens fichiers PDB (si c'est possible), puis renomme tout ce qui reste avec une extension .old.pdb . Un bon effet secondaire 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 que vous ferez une build.

Par exemple, build / debug session 1 laisse MyProject.pdb verrouillé.
La prochaine fois que vous construisez:
MyProject.pdb -> MyProject.old.pdb

Ensuite, build / debug session 2 est démarré, et MyProject.pdb et MyProject.old.pdb sont toujours verrouillés:
MyProject.old.pdb -> MyProject.old.old.pdb
MyProject.pdb -> MyProject.old.pdb

Enfin, redémarrer Visual Studio et faire une nouvelle construction va se débarrasser de ces deux, et continuer le processus comme d'habitude.


Il semble que par changement le nom d'assembly d'un projet résout le problème.

Donc, au lieu de cela

Je le change à ceci

Notez que je l'ai juste changé de Increment and Recall à Increment_Recall , je viens de supprimer les espaces. Cela fonctionne maintenant bien pour moi.


J'ai été capable de 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"

J'ai fait face au même problème sur VS 2012 Version 11.0.60610.01 Mise à jour 3 sur Windows 8

Il n'y avait aucune fenêtre de concepteur ouverte et le projet était une application console simple.

La suppression du processus vshost accédant au fichier ne fonctionne pas la plupart du temps puisque 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 à ajouter 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 connais.

J'espère que cela t'aides...


J'ai remarqué quelques réponses qui ont résolu mon problème, mais au cas où quelqu'un aurait le même problème que moi.

SI VOUS UTILISEZ UNE APPOLE CONSOLE: AVANT DE FAIRE TOUT AUTRE.

Assurez-vous d'avoir fermé toutes les fenêtres de console qui ont pu être ouvertes à partir d'une version précédente. Par exemple, je ne faisais que tester du code dans une application de console, je n'avais pas réalisé que la fenêtre de la console de l'une des fois où j'avais lancé mon programme était ouverte. Pendant cette session j'étais en train de déboguer, la fenêtre a été poussée à l'arrière et je ne pouvais pas le voir. Juste en disant, cela pourrait être votre problème, alors vérifiez pour vous assurer que ce n'est pas le problème.


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


Je ne me suis pas rendu compte que j'avais toujours mon débogueur attaché et essayait de construire dans la même instance de Visual Studio. Une fois que j'ai arrêté le débogueur, j'ai pu construire.


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).
Ça a bien fonctionné pendant un certain temps depuis que je l'ai décoché.
J'utilise les commandes MySql NET Connector et DevExpress dans mon projet. Peut-être que l'un d'entre eux ne disposait pas de connexions, de liaisons, etc. à cause de ce drapeau qui était activé.

EDITED: certainement ça marche! Plus de 'Impossible de copier le fichier' et plus d'erreurs du Concepteur de Formulaire.


Je reçois cela chaque fois que je déploie si je modifie une page Xaml sur WP8 en utilisant VS2012.

Je dois soit ne pas ouvrir une page Xaml ou utiliser l'explorateur de processus pour tuer le processus XDesProc.exe.

Si vous obtenez cette erreur, je recommande d'utiliser l'explorateur de processus pour voir ce qui se passe (même si c'est un problème différent). Il suffit de trouver le processus "WeinGartner.WeinCad.exe" et il devrait montrer le processus et gérer l'accès au fichier (enfin au moins quand le fichier vhost ne corrige pas le problème).


Ma contribution de 10 cents.

J'ai toujours ce problème parfois 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 est parti.

Stefano


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


Solution: Redémarrez le système d'exploitation, cela fonctionne toujours pour moi, en raison du processus vshost ne peut pas être terminé parfois.

Ce bug 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


Tuer le (s) processus (s) vstest.executionengine.exe résout ce problème 90% du temps pour moi. Si cela ne fonctionne pas, alors tuer QTAgent32.exe et ensuite supprimer les dossiers / bin et / obj pour le projet en question fonctionne.

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


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


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 / constructeur crée le fichier .exe identifié comme une menace par Avast et donc supprimé juste avant qu'il puisse être exécuté par VS.





process