La compilation de Visual Studio échoue: impossible de copier le fichier exe d'objdebug vers bindebug

j'ai trouvé une solution simple, juste désactiver les services D'indexation Windows pour le dossier de projet et les sous-dossiers

comme je n'ai pas eu plus de commentaires sur cette question, j'ai pensé que je voudrais juste partager ce qui a fini par être ma solution:

comme le suggère Barry dans un commentaire au billet original, renommant manuellement le "...bin\Debug[ProjectName].exe ' à autre chose (p.ex. '[nom du projet]1.exe ' ) est un work-around (Je ne suis cependant pas autorisé à supprimer le fichier moi-même, et je dois dire que je trouve que un peu bizarre comme on pourrait croire même serrure empêchant la suppression empêcherait également renommer...). Ce n'est pas une bonne solution, mais c'est assez rapide (au moins après l'avoir fait quelques fois, ça devient presque une routine), et au moins beaucoup plus rapide que le redémarrage de Visual Studio, ce que j'ai fait au début.

dans le cas où quelqu'un se demande, je pourrais également ajouter que je ne vois ce problème semi-aléatoire. Cela se produit habituellement après que j'ai fait quelques changements dans le mode de conception d'une forme (mais pas toujours). Il en général, cela ne se produit pas si Je ne change que le code logique de l'entreprise ou le code connexe non visuel (mais parfois cela se produit...). Frustrant en effet, mais au moins j'ai un hack qui fonctionne pour moi - espérons juste que mon prochain projet ne fait pas face à ce problème aussi bien...

@Barry: si vous voulez obtenir un crédit pour votre commentaire, n'hésitez pas à poster une réponse et je vais m'assurer de l'accepter :)

j'ai le même problème (MSB3021) avec le projet WPF en VS2008 (sur Windows 7 x32). Le problème apparaît si j'essaie de relancer l'application trop vite après la course précédente. Après quelques minutes exe-fichier déverrouillé par lui-même et je peux relancer l'application. Mais une si longue pause me met en colère. la seule chose qui m'a vraiment aidé a été courir VS en tant qu'administrateur.

quand je suis tombé sur ce problème, il est à voir avec le fait que le projet que j'essaie de construire est défini comme le projet de démarrage dans la solution faisant le .exe dans le dossier obj verrouillé ( il apparaît aussi dans votre gestionnaire de tâches), cliquez avec le bouton droit de la souris sur un autre projet dans votre solution et choisissez set startup project. Cela va libérer le verrou, le retirer du Gestionnaire des tâches et devrait vous permettre de construire.

j'ai essayé tous les autres suggestions dans les réponses ici, aucun n'a fonctionné. Finalement, J'ai utilisé Process Monitor pour découvrir que mon .exe qui VS2010 n'était pas de construire a été verrouillé par le Système de processus (PID=4). En cherchant ainsi des situations impliquant ceci a donné cette réponse .

résumé: si vous avez le service D'expérience de L'Application désactivé (comme je l'ai fait) puis re-activer et démarrer. Deux ans d'aggravation ont pris fin.

j'ai aussi eu un problème très similaire à celui-ci et j'ai trouvé que la raison dans mon cas était que j'avais rendu le dossier bin\debug disponible en tant que dossier partagé sous VMware et soit VMware, explorateur sous le guest VM, ou peut-être même un programme antivirus sous le guest (bien que je ne pense pas en avoir un installé) tenait une poignée vers le(S) fichier (s).

Désactiver "Activer le processus D'hébergement Visual Studio"

SI VOTRE PROBLÈME N'EST PAS ENCORE RÉSOLU:

L'erreur de Visual studio est:

"Le processus ne peut pas accéder au fichier 'bin\Debug**app.exe**', car il est utilisé par un autre processus."

alors, allez à Gestionnaire des tâches de windows (Ctrl+Shift+Esc),trouvez le nom de votre application et le forcer à fermer avant la fin du processus.

en utilisant Visual Studio Je n'ai jamais pu trouver un simple projet pour reproduire l'erreur.

ma solution a été de désactiver le processus D'hébergement Visual Studio.

pour ceux qui sont intéressés j'ai attaché une trace de poignée pour la poignée offensante:

0:044> !htrace 242C
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x000000007722040a: ntdll!ZwCreateFile+0x000000000000000a
0x0000000074b4bfe3: wow64!whNtCreateFile+0x000000000000010f
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0066: ntdll_773b0000!NtCreateFile+0x0000000000000012
0x000000007541b616: KERNELBASE!CreateFileW+0x000000000000035e
0x0000000075b42345: KERNEL32!CreateFileWImplementation+0x0000000000000069
0x000000006a071b47: mscorwks_ntdef!StgIO::Open+0x000000000000028c
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
*** WARNING: Unable to verify checksum for mscorlib.ni.dll
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x00000000000006cc, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130
0x0000000075b427b5: KERNEL32!RegOpenKeyExW+0x0000000000000021
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130

--------------------------------------
Parsed 0x358E stack traces.
Dumped 0x7 stack traces.
0:044> !handle 242c ff
Handle 242c
  Type          File
  Attributes    0
  GrantedAccess 0x120089:
         ReadControl,Synch
         Read/List,ReadEA,ReadAttr
  HandleCount   2
  PointerCount  3
  No Object Specific Information available

Voici une autre possibilité:

après avoir reçu cette erreur dans vs2012 / win7, je suis allé et essayé de supprimer le fichier dans le répertoire bin et l'explorateur a indiqué que le fichier était en usage par le concepteur D'UI de XAML.

j'ai fermé tous les onglets que j'avais ouvert dans VS, fermé VS, puis je me suis assuré de tuer tous les processus MSBuild dans taskmanager. Finalement, après avoir redémarré VS j'ai pu construire la solution.

et une autre cause possible:

j'ai remarqué une autre cause possible pour ce problème. Après avoir fait quelques remaniements de code, déplacer des projets dans et Hors d'une solution, mes références de projet ne faisaient plus référence aux projets dans la solution comme prévu.

ce studio visuel induit en erreur de penser qu'il pourrait construire certains projets simultanément, créant ainsi les verrous de fichier.

EDIT: Cela m'est arrivé à quelques reprises, même récemment avec VS2012, et il le corrige une fois que j'ai défini l'ordre de construction aux dépendances correctes, que j'ai désactivé tout processus msbuild que VS a laissé tourner, puis que J'ai redémarré VS. Je tue les processus msbuild juste pour être sûr, mais fermer VS devrait les tuer aussi.

ce que je fais habituellement pour causer ceci est de remanier un projet tel qu'il s'appuie sur un autre projet dans la solution qu'il ne référençait pas sur la dernière construction. Parfois, cela semble confondre VS et il ne met pas à jour l'ordre de construction.

pour vérifier l'ordre de construction: droit-cliquez la Solution dans L'Explorateur de solutions et sélectionnez" Ordre de construction de projet..."et vérifier que les dépendances sont bien notés pour chaque projet.

redémarrer IIS - pourrait être un processus attaché au débogueur

désactivez l'antivirus et essayez. J'ai aussi été confronté à ce problème... mais dans mon cas, l'antivirus bloquait mon application quand j'ai désactivé l'antivirus.

j'ai fait face à la même erreur.

j'ai résolu le problème en supprimant tout le contenu des dossiers bin de tous les projets/bibliothèques dépendants.

cette erreur se produit principalement en raison de changements de version.

je vous suggérerais de télécharger Process Explorer pour savoir exactement quel processus verrouille le fichier. Il peut être trouvé à:

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

cela a été enregistré plusieurs fois sur Connect, le site de notification de bogues de la communauté de Microsoft. Pour info, je crois que ce bug affecte Visual Studio depuis 2003 et a été corrigé après RTM à chaque fois. (L'une des références est la suivante:

https://connect.microsoft.com/VisualStudio/feedback/details/568672/handles-to-project-dlls-are-not-released-when-compiling?wa=wsignin1.0

si aucune des solutions ci-dessus ne fonctionne, et que vous développez une application de console:

essayez de taper n'importe quel caractère dans le programme.cs, puis supprimez-le. Je n'ai aucune idée pourquoi cela fonctionne, mais il semble résoudre "incapable de copier" problème à chaque fois.

c'est plutôt fréquent causé par Avast.

je peux généralement lancer mes projets dans la version indépendamment, mais en cours d'exécution dans debug il serait assez régulièrement échouer.

j'ajoute juste une exclusion pour mon dossier projets et le problème semble disparaître. Je suppose que cela pourrait aussi être causé par d'autres logiciels antivirus.

Renuméroter le .exe et .le dossier du pub marchait pour moi, mais c'était ennuyeux. Je fais aussi face au problème que je n'ai pas pu éditer lors d'une session de débogage. Enfin je suis allé à la page de configuration de sécurité avancée, comme suit:

https://msdn.microsoft.com/query/dev10.query?appId=Dev10IDEF1&l=EN-US&k=k%28%22VS.ERR.DEBUG_IN_ZONE_NO_HOSTPROC%3a11310%22%29;k%28TargetFrameworkMoniker-%22.NETFRAMEWORK%2cVERSION%3dV4.0%22%29&rd=vrai

Je dés-sélectionne puis re-sélectionne la case à cocher" Activer les paramètres de sécurité ClickOnce". C'est sans problème depuis quelques jours maintenant....

pour moi, cela était dû au fait qu'une invite de commande était ouverte dans le dossier ciblé ( C:\users\username\source\repos\project\project\bin\debug\app.publish ).

Je ne sais pas pourquoi le débogage nécessite l'accès au dossier publier, mais fermer la fenêtre de commande a résolu le problème pour moi.

j'ai essayé plusieurs solutions que vous avez fournies, mais de temps en temps je reçois toujours cette erreur. Je suis certain que mon processus ne fonctionne pas, et quand j'essaie de supprimer le fichier exécutable avec internet explorer, il est supprimé de la liste des fichiers, mais ensuite j'appuie sur F5 et voila, le fichier est de retour. Il n'a pas été supprimé.

mais si je supprime le fichier via le Totcommander, le fichier exe est en fait supprimé et je peux construire le projet avec succès.

j'utilise windows 7 x64 et total commander 7.56 a 32 bit.

aucune des autres réponses n'a fonctionné pour moi, mais fermer tous les onglets ouverts dans Visual Studio semble avoir résolu le problème.

je sais que c'est une question très ancienne, mais j'ai récemment connu l'erreur" ne peut pas copier de obj à bin " dans VS 2012. Chaque fois que j'ai essayé de reconstruire un projet, j'ai reçu le message. La seule solution était de faire un nettoyage avant chaque reconstruire.

après beaucoup d'enquête, il s'avère que j'ai eu un avertissement pragma incomplet dans un de mes dossiers qui n'a pas empêché la compilation de réussir, mais était en quelque sorte confuse VS dans Garder la fichier(s) verrouillé.

dans mon cas, j'avais ce qui suit en haut du dossier:

#pragma warning(

C'est ça. Je suppose que j'ai essayé de faire quelque chose il y a quelque temps et j'ai été distrait et je n'ai jamais fini le processus, mais les avertissements de VS à propos de cette ligne particulière ont été perdus dans le mélange. Finalement, j'ai remarqué l'avertissement, supprimé la ligne, et de reconstruire qui fonctionne à chaque fois depuis.

faire les choses simples d'abord.

Vérifiez qu'une partie de votre solution n'est pas verrouillée par un processus en cours d'exécution.

par exemple, j'ai lancé "InstallUtil" sur mon service windows(que je teste normalement sur une console).

ceci a verrouillé certains de mes dlls dans le dossier bin du projet windows service. Quand j'ai fait une reconstruction, j'ai eu l'exception dans ce numéro.

j'ai arrêté le service de fenêtres, reconstruit et il a réussi.

Vérifiez Windows Task Manager pour votre Application, avant de faire l'une des étapes préalables dans ce numéro.

donc quand vous entendez des pas, pensez Chevaux pas zèbres! (d'un ami étudiant en médecine)

quand j'ai fait face à une question similaire, la seule chose qui semblait fonctionner était:

• cliquez avec le bouton droit de la souris sur le projet, allez dans Paramètres, et assurez-vous que les deux constructions Debug et Release ciblent les mêmes paramètres, ou ont les paramètres que l'application essaie de charger ou d'enregistrer.
• supprimant la C:\Users(YourUserAccount)\AppData\Local (YourAppName) folder.
• en S'assurant qu'il n'y avait pas de fichiers considéré comme "Bloqué". En faisant un clic droit sur les fichiers inclus dans mon projet, j'ai réalisé qu'une icône était en fait bloquée et considérée comme mauvaise parce qu'elle avait été téléchargée à partir d'internet. J'ai dû cliquer sur le bouton Débloquer (en exemple, regardez ceci: http://devierkoeden.com/Images/Articles/Dynamicweb/CustomModules/Part1/BlockedFiles.png - " ce fichier provient d'un autre ordinateur et pourrait être bloqué pour aider à protéger cet ordinateur.").

pour les Services Windows utilisant WCF, j'ai terminé le processus hôte WFC et ça a marché. Je déteste quand ça arrive, et ça arrive au hasard.

ma solution n'a rien à voir avec les versions, les processus étant verrouillés, redémarrant ou supprimant des fichiers.

le problème était en fait dû à la défaillance de la construction, et ne pas donner l'erreur correcte. Le véritable problème était un défaut de conception:

// Either this should be declared outside the function, or..
SomeObject a = new SomeObject(); 

Task.Factory.StartNew(() =>
{
   while (true)
   {
      a.waitForSomething();
   }
});

// ...this should not be called
a.doSomething(); 

après avoir changé la portée de" a "à l'extérieur de la fonction, ou ne pas utiliser" a "Après Task.Factory.StartNew(); , j'ai été en mesure de construire à nouveau.

C'est arrivé lors de L'utilisation de VS2012 mise à jour 4 sur Windows7x64 sp1.

message d'erreur:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets (3390,5): erreur MSB3030: ne pouvait pas copier le fichier "obj\x86\Debug\xxx.exe" parce que il n'a pas été trouvé.

j'ai trouvé avec VS2013 je reçois cette erreur régulièrement. Quelque chose qui semble fonctionner raisonnablement bien est d'effectuer une solution de reconstruction avant d'essayer d'exécuter l'application. J'ai constaté que la réalisation d'un nettoyage fonctionne parfois, mais la solution de reconstruction semble fonctionner de manière plus cohérente.

j'ai eu le même problème. Il a dit ne pouvait pas copier de bin\debug à obj.....

quand je construis projet web j'ai trouvé ma dll étaient tous dans le dossier de bin et pas dans bin\debug. Au cours de publish vs était à la recherche de fichiers dans bin\debug. J'ai donc ouvert le fichier de projet web dans editor et j'ai cherché des instances de bin\debug et j'ai trouvé que toutes les dll étaient mentionnées comme bin\debug\mylibrary.DLL. J'ai supprimé tout \debug du chemin et l'ai publié à nouveau. Cette fois vs a pu trouver toute la dll dans bin dossier et publier réussi.

je n'ai aucune idée de comment ce chemin a été changé dans le fichier de projet web.

j'ai passé plus de 5 heures à le déboguer et j'ai finalement trouvé la solution toute seule.

C'est la bonne réponse .

cela m'aide après que j'ai enlevé le drapeau read only du répertoire bin. http://www.thewindowsclub.com/error-0x80080015-windows-defender-activation-requires-display-name