Impossible de copier un fichier d'obj\Debug vers bin\Debug
J'ai un projet en C # et j'obtiens cette erreur chaque fois que j'essaie de le compiler:
(Impossible de copier le fichier "obj\Debug\Project1.exe" dans "bin\Debug\Project1.exe". Le processus ne peut pas accéder au fichier "bin\Debug\Project1.exe" car il est utilisé par un autre processus.)
... donc je dois fermer le processus à partir du gestionnaire de tâches. mon projet n'est qu'une forme et il n'y a pas de multi-threading.
quelle est la solution (sans redémarrer VS ou Killing the process)?
c'est le code d'erreur que nous avons. Comment pouvons-nous résoudre ce problème?
@Udpate: Depuis que j'ai posté cette réponse pour la première fois, j'ai tendance à donner une autre explication au problème. Depuis lors, le problème se pose de plus en plus souvent en dehors de Visual Studio, tout en essayant de copier un fichier .exe d'un dossier à un autre. Tandis qu’en premier lieu, Windows ne permettait pas de copier (!) Un fichier .exe (il me demandait d’abord des droits d’administrateur, mais refusait de le copier après tout de même). Mais après un certain temps - sans aucune autre action entreprise, il disparut comme par magie. Tout comme le problème dans la question semble toujours se résoudre après un certain temps. Donc, je suppose que le problème est davantage lié à une suppression retardée du fichier de sortie du projet et moins à un problème VS. Je m'excuse pour tout soupçon injustifié. : |
Cela donne à la recherche d'une solution une direction complètement différente, je suppose. Avez-vous trouvé ce lien et resterez-vous au courant de tout progrès:
https://superuser.com/questions/234569/windows-7-delayed-file-delete
=============================================== =======================
C'est un bug connu dans VS. Je l'ai découvert très souvent - principalement dans VS2010 (avec/sans SP1). Plusieurs "solutions" sont recommandées. Certains d’entre eux, ce qui m’a aidé:
- Supprimez le fichier .suo dans votre répertoire de projet. Finalement, vous devez créer votre solution complète à partir de zéro.
- Fermez les concepteurs Windows Form peuvent rester ouverts.
- Utilisez un script de pré-construction, qui supprime la cible du répertoire de sortie.
- Désactiver le processus d'hébergement VS.
Aucun de ceux-ci ne corrige vraiment le bogue. Mais cela peut ramener le système virtuel à un état utilisable - jusqu'à ce qu'une solution véritable soit fournie par MS (si jamais cela sera possible).
http://social.msdn.Microsoft.com/Forums/en/vsdebug/thread/cea5e4b2-5b33-453c-bffb-8da9f1a1fa4a
http://social.msdn.Microsoft.com/Forums/en/vbide/thread/cd12f3c7-de96-4353-adce-23975e30933f
Je peux également confirmer que ce bogue existe dans VS 2012 Update 2.
Mon travail consiste à:
- Solution propre (et ne rien faire d'autre)
- Fermez tous les documents/fichiers ouverts dans la solution
- Sortie VS 2012
- Run VS 2012
- Solution de construction
Je ne sais pas si cela est pertinent ou non, mais mon projet utilise des fichiers "liés" dans la classe d'autres projets. Il s'agit d'un projet Silverlight 5 et le seul moyen de partager une classe compatible .NET et SL est de lier des dossiers.
Quelque chose à considérer ... recherchez des fichiers liés dans plusieurs projets dans une solution unique.
Cela devrait marcher.
Accédez aux propriétés de votre projet. Inside Build Events, sous Ligne de commande de l'événement de pré-génération, ajoutez ces deux lignes de code:
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
Si vous regardez dans le répertoire obj et que vous ne voyez pas votre fichier .exe, il est possible que Avast! ou un autre antivirus est en train de le supprimer. En fait, je verrais le fichier .exe apparaître puis disparaître. Dès que j'ai éteint Avast !, le problème est résolu.
Le vrai problème n'est pas l'erreur que vous obtenez; c'est que l'application ne nettoie pas toute seule.
Il s’agit soit de conserver des références, mais pas de libérer des ressources, soit de faire en sorte que le processus ne se termine pas lorsqu’on lui dit de fermer. Corrigez ce problème et ce problème va se résoudre tout seul. Nous ne pouvons vraiment pas vous aider si vous postez votre code (et à ce stade, si vous avez besoin d'aide, vous devriez poser une nouvelle question).
Je devais aller dans Windows Explorer et supprimer le dossier bin/debug ainsi que les dossiers obj/debug. Ensuite, j'ai nettoyé et reconstruit le projet.
Cela se produit car le processus [yourProjectName].exe ne se ferme pas une fois le débogage terminé.
Il y a deux solutions pour ce problème.
Chaque fois que vous modifiez une application, accédez au Gestionnaire de tâches -> Processus -> [votreNomProjet] .exe, terminez ce processus. Vous devez mettre fin à ce processus chaque fois que vous apportez des modifications au système.
Ajouter un bouton de sortie dans votre application pour quitter la fenêtre et ajouter cette ligne pour cliquer sur l'événement
System.Diagnostics.Process.GetCurrentProcess().Kill(); Application.Exit();
Après avoir vu une erreur similaire dans les studios visuels 2012 de nulle part. J'ai trouvé que cela va dans le dossier racine du projet et que je clique dessus avec le bouton droit de la souris, j'ai décoché en lecture seule et cette erreur a disparu Apparemment, TFS créera parfois un dossier en lecture seule. Espérons que cela aidera tout le monde avec un problème similaire. Merci
C'est ce qui m'est arrivé à VS 2010 et à Win 7 ..
- Je ne peux pas reconstruire avec le gestionnaire de configuration Debug, mais je peux reconstruire avec le gestionnaire de configuration
Ce que j'ai essayé
- Vérifiez mon type de compte sur le panneau de commande - compte d'utilisateur -> Mon compte est administrateur
- Définir le dossier bin non en lecture seule
- Ajouter la sécurité dans le dossier bin à Tout le monde
- arrêtez le serveur IIS
Arrêtez l'antivirus, vérifiez le programme en cours d'exécution ridicule en utilisant le gestionnaire de tâches et ProcessExplorer
exécuter VS en tant qu'administrateur
Si tout ce chemin ne fonctionne toujours pas.
Ensuite, le dernier moyen d'essayer:
- solution proche
- fermer studio visuel
- démarrer - arrêter
- appuyez sur le bouton d'alimentation pour allumer l'ordinateur
- connectez-vous à votre compte qui a previlege administrateur au type d'utilisateur
- rouvrir la solution
- reconstruire
- de cette façon fonctionne. Toutes les personnes appellent de cette façon comme Reset Computer
- Fermez votre projet
- Supprimer le dossier bin
je trouve ça marche, :)
Avant de reconstruire la solution, effacez le projet , arrêtez le IIS et ouvrez la propriété "bin" dossier. Décochez l'onglet Attribut en lecture seule en général puis reconstruisez.
Renommez l'Assemblée sous un nom différent pour résoudre ce problème.
J'ai eu le même problème, après avoir lu vos réponses, je suis allé à Task Manager et j'ai cherché app.exe parce que je crois que ça ne ferme peut-être pas.
Et trouvé, sélectionnez-le et faites END TASK. Mon problème résolu.
J'ai constaté que la fin de toutes les tâches msbuild.exe (dans le Gestionnaire des tâches) résolvait le problème avec VS2012.
Si d'autres suggestions ne vous convenaient pas, la solution proposée à cette adresse m'a aidé: http://weblogs.asp.net/fmarguerie/archive/2009/01/29/life-changer-xaml-tip) -for-visual-studio.aspx
cette question est également liée au problème suivant: VS2012 - XDesProc se bloque à l’ouverture du fichier Xaml } _
par une raison quelconque, lorsque j’ouvre le fichier XAML puis que je le construit, le processus XDesProc reste en mémoire lors de l’utilisation du fichier dll de l’assemblée principale.
Eh bien, j'ai le même problème, ma façon de le résoudre était d'arrêter et de désactiver le service "Expérience d'application" dans Windows.
Exécuter Visual Studio en tant que Administrator
J'ai résolu ce problème en tuant XDesProc qui avait un handle sur la DLL qu'il ne pouvait pas supprimer.
Nous avons récemment fait l'expérience de cela sur un projet WinPhone 8, dans VS 2012 Update 2.
De manière inexplicable, la cause était d'utiliser le type Tuple. En supprimant le code qui utilisait un Tuple, le problème a disparu. Ajoutez le code de retour le problème renvoyé.
pour moi, c'était l'antivirus. Ajoutez simplement un projet Visual Studio ou un dossier parent entier à la liste d'exclusion antivirus. Vous pouvez également ajouter une extension de fichier comme exclusion. Cette méthode a fonctionné pour moi dans visual studio 2010/2012
J'ai lutté avec cela depuis des années. J'ai finalement téléchargé LockHunter pour savoir qui a verrouillé le fichier . Dans mon cas, il s'agissait de MBAM. Une fois que j'ai ajouté le répertoire de mon projet à la liste d'exclusion MBAM, je n'ai plus eu ce problème.
Le mien a été résolu par:
- Solution propre
- Fermez tous les processus en fonction de VS (instances actuelles).
- Reconstruire
Pas une réponse directe à votre question.
Un scénario où cela peut venir est énuméré ci-dessous -
Si votre application est en cours de débogage - disons par le débogage "Attacher au processus", cette erreur peut venir
Cela semblera fou, chaque fois que je construirai le projet, l'erreur sera affichée et l'antivirus avast le montrera comme une tentative malveillante et le projet ne s'exécutera pas. été créé et le projet a été exécuté avec succès.
Ou tu peux essayer ça
après jour avec chercher et construire et reconstruire j'ai trouvé que vous avez juste besoin d'éteindre allumer le studio visuel son look comme il attraper le service dans fil
Une solution très simple consiste à ouvrir le gestionnaire de tâches (CTRL + ALT + SUPPR), à accéder à l'onglet Processus et à rechercher par nom les processus portant encore le nom de votre projet en cours d'exécution. Tuez tous les processus et continuez! :)
Si cette erreur s'est produite, vous pouvez procéder comme suit
- Terminez la tâche
msbuild.exe - Terminez la tâche
Explorer.exe - Exécutez à nouveau la tâche
Explorer.exe