Echec de la construction de Visual Studio: impossible de copier le fichier exe d'obj\debug vers bin\debug
Update: _ Un exemple de projet reproduisant ce bogue peut être trouvé ici sur Microsoft Connect . J'ai également testé et vérifié que la solution donnée dans la réponse acceptée ci-dessous fonctionne sur cet exemple de projet. Si cette solution ne fonctionne pas pour vous, vous rencontrez probablement un problème différent (qui fait l'objet d'une question distincte).
Cette question a déjà été posée, à la fois ici, sur Stack Overflow et d’autres endroits, mais aucune des suggestions que j’ai trouvées jusqu’à présent ne m’a aidé, je dois donc essayer de poser une nouvelle question.
Scénario: J'ai une application Windows Forms simple (C #, .NET 4.0, Visual Studio 2010). Il a quelques formulaires de base dont héritent la plupart des autres formulaires, il utilise Entity Framework (et les classes POCO) pour l’accès à la base de données. Rien d'extraordinaire, pas de multi-threading ou quoi que ce soit.
Problème: tout allait bien pendant un moment. Puis, à l’improviste, Visual Studio n’est pas parvenu à créer lorsque j’étais sur le point de lancer l’application. J'ai reçu l'avertissement "Impossible de supprimer le fichier '... bin\Debug\[NomProjet] .exe'. L'accès au chemin '... bin\Debug\[NomProjet] .exe' est refusé." et l'erreur "Impossible de copier le fichier 'obj\x86\Debug\[NomProjet] .exe' vers 'bin\Debug\[NomProjet] .exe'. Le processus ne peut pas accéder au fichier 'bin\Debug \. [NomProjet] .exe 'car il est utilisé par un autre processus. " (Je reçois à la fois l'avertissement et l'erreur lors de l'exécution de la reconstruction, mais uniquement l'erreur lors de l'exécution de la compilation - vous ne pensez pas que cela est pertinent?)
Je comprends très bien ce que le message d’avertissement et d’erreur dit: Visual Studio essaie évidemment d’écraser le fichier exe alors qu’il détient un verrou pour une raison quelconque. Cependant, cela ne m'aide pas à trouver une solution au problème ... La seule chose que j'ai trouvée qui fonctionne est de fermer Visual Studio et de le redémarrer. La construction et le lancement fonctionnent alors, jusqu’à ce que je modifie certaines des formes, puis j’ai à nouveau le même problème et je dois le redémarrer ... Assez frustrant!
Comme je l’ai mentionné ci-dessus, il semble que ce problème soit connu. Il existe donc de nombreuses solutions suggérées. Je vais juste énumérer ce que j'ai déjà essayé ici, pour que les gens sachent quoi sauter:
- Créez une nouvelle solution propre et copiez simplement les fichiers de l'ancienne solution.
Ajoutez ce qui suit à l'événement de pré-génération du projet:
if exist "$(TargetPath).locked" del "$(TargetPath).locked" if not exist "$(TargetPath).locked" if exist "$(TargetPath)" move "$(TargetPath)" "$(TargetPath).locked"Ajouter ce qui suit aux propriétés du projet (fichier .csproj):
<GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>
Cependant, aucun d'entre eux n'a fonctionné pour moi, alors vous pouvez probablement voir pourquoi je commence à être un peu frustré. Je ne sais pas où chercher, alors j'espère que quelqu'un a quelque chose à me donner! Est-ce un bogue dans VS, et si oui, existe-t-il un correctif? Ou ai-je fait quelque chose de mal, ai-je une référence circulaire ou similaire, et si oui, comment pourrais-je le savoir?
Toutes les suggestions sont très appréciées :)
Update: Comme mentionné dans le commentaire ci-dessous, j'ai également vérifié à l'aide de Process Explorer qu'il s'agissait bien de est Visual Studio qui verrouille le fichier.
Cela va paraître stupide, mais j'ai essayé toutes ces solutions, exécutant VS2010 sous Windows 7. Aucune d'entre elles ne fonctionnait à l'exception du changement de nom et de la construction, ce qui était TRES fastidieux pour le moins. Finalement, j'ai retrouvé le coupable et j'ai du mal à le croire. Mais j'utilisais le code suivant dans AssemblyInfo.cs ...
[Assembly: AssemblyVersion("2.0.*")]
C'est assez courant, mais pour une raison quelconque, le passage de la version à la version 2.0.0.0 a permis de rétablir le fonctionnement. Je ne sais pas s'il s'agit d'un logiciel spécifique à Windows 7 (je ne l'utilise que depuis 3 ou 4 semaines), ou si c'est aléatoire, ou quoi, mais cela a résolu le problème pour moi. J'imagine que VS gardait une trace de chaque fichier généré pour pouvoir incrémenter les choses? Je ne suis vraiment pas sûr et je n'ai jamais vu cela se produire auparavant. Mais si quelqu'un d'autre s'arrache les cheveux, essayez-le.
J'ai trouvé une solution simple, il suffit de désactiver les services d'indexation Windows pour le dossier et les sous-dossiers du projet.
Comme je n'ai plus eu de retour sur ce problème, je pensais simplement partager ce qui a fini par être ma solution:
Comme suggéré par Barry dans un commentaire sur le message d'origine, renommez manuellement le '... bin\Debug [NomProjet] .exe' en autre (par exemple '[NomProjet] 1.exe' ) est un moyen de contourner le problème (je ne suis cependant pas autorisé à supprimer le fichier moi-même, et je dois dire que je trouve cela un peu bizarre de penser que le même verrou empêchant la suppression empêcherait également le renommage ...) Ce n'est pas une bonne solution, mais c'est assez rapide (du moins après l'avoir fait plusieurs fois, cela devient presque une routine) et au moins bien plus rapidement que de redémarrer Visual Studio, comme je l'avais fait au début.
Au cas où quelqu'un se demanderait, je pourrais aussi ajouter que je ne vois ce problème que de manière semi-aléatoire. Cela se produit généralement après quelques modifications apportées au mode de création d'un formulaire (mais pas toujours). Cela ne se produit généralement pas si je ne change que le code de la logique métier ou le code associé non visuel (mais parfois, cela se produit ...). Frustrant certes, mais au moins j'ai un bidouillage qui fonctionne pour moi - espérons juste que mon prochain projet ne soit pas aussi confronté à ce problème ...
@Barry: si vous souhaitez obtenir un crédit pour votre commentaire, n'hésitez pas à le poster en tant que réponse et je m'assurerai de l'accepter :)
J'ai le même problème (MSB3021) avec le projet WPF dans VS2008 (sous Windows 7 x32) . Le problème apparaît si j'essaie de réexécuter l'application trop rapidement après l'exécution précédente . Après quelques minutes, exe-file déverrouillé par lui-même et je peux réexécuter l'application à nouveau. Mais une si longue pause me met en colère .. La seule chose qui m'a vraiment aidé a été de lancer VS en tant qu'administrateur.
Lorsque j’ai rencontré ce problème, c’est que le projet que j’essaie de construire est défini comme projet de démarrage dans la solution, ce qui permet de verrouiller le fichier .exe du dossier obj (il apparaît également dans votre gestionnaire de tâches) Cliquez avec le bouton droit de la souris sur un autre projet de votre solution et choisissez Définir le projet de démarrage. Cela libère le verrou, le supprime du gestionnaire de tâches et devrait vous permettre de construire.
J'ai essayé toutes les autres suggestions dans les réponses ici, dont aucune n'a fonctionné. Finalement, j'ai utilisé Process Monitor pour découvrir que le fichier système (PID = 4) bloquait le fichier .exe que VS2010 ne parvenait pas à générer. La recherche SO pour les situations impliquant cela a donné ceci réponse.
Résumé: si le service Application Experience est désactivé (comme je l'ai fait), réactivez-le et démarrez-le. Deux années d'aggravation ont pris fin.
J'ai également eu un problème très similaire à celui-ci et la raison dans mon cas était que j'avais rendu le dossier bin\debug disponible en tant que dossier partagé sous VMware et VMware, Explorer sous l'invité VM ou même peut-être un programme anti-virus sous l'invité (bien que je ne pense pas en avoir installé un) contenait une poignée pour le (s) fichier (s).
Désactiver "Activer le processus d’hébergement Visual Studio" 
SI VOTRE PROBLÈME IS N'EST PAS RÉSOLU ENCORE:
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 dans le gestionnaire de tâches de Windows (Ctrl + Maj + Échap), trouvez le nom de votre application et le forcer à fermer par les procédures finales.
À l'aide de Visual Studio, je n'ai jamais pu créer un projet simple pour reproduire l'erreur.
Ma solution était de désactiver le processus d'hébergement Visual Studio.
Pour les personnes intéressées, j'ai joint une trace de poignée pour la poignée incriminée:
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
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 survient principalement en raison de changements de version.
Désactivez l'antivirus et essayez. J'ai également été confronté à ce problème ... mais dans mon cas, l'antivirus bloquait mon application lorsque je l'ai désactivé, il a été résolu.
Redémarrer IIS - pourrait être un processus attaché au débogueur
Voici une autre possibilité:
Après avoir reçu cette erreur dans vs2012/win7, je suis allé et j'ai essayé de supprimer le fichier dans le répertoire bin et Explorer a indiqué que le fichier était utilisé par le concepteur d'interface utilisateur XAML.
J'ai fermé tous les onglets que j'avais ouverts dans VS, je les ai fermés, puis je me suis assuré de supprimer tous les processus MSBuild dans le gestionnaire de tâches. 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 à ce problème. Après avoir refactorisé le code et déplacé des projets dans une solution, mes références de projet ne faisaient plus référence aux projets de la solution comme prévu.
Visual Studio a induit le studio en erreur en lui faisant croire qu'il pourrait construire certains projets simultanément, créant ainsi des verrous de fichiers.
EDIT: Cela m'est arrivé à quelques reprises, même récemment, avec VS2012, et le problème est résolu une fois que j'ai défini l'ordre de construction sur les dépendances correctes, que tous les processus msbuild laissés en cours d'exécution ont été supprimés, puis redémarré VS. Je tue les processus msbuild juste pour être sûr, mais fermer VS devrait également les tuer.
Ce que je fais habituellement pour provoquer ceci est de refactoriser un projet de telle sorte qu'il repose sur un autre projet de la solution qu'il ne référençait pas lors de la dernière construction. Cela semble parfois dérouter VS et il ne met pas à jour l'ordre de construction.
Pour vérifier l'ordre de construction: Cliquez avec le bouton droit de la souris sur la solution dans l'explorateur de solutions, sélectionnez "Ordre de construction du projet ..." et vérifiez que les dépendances sont correctement notées pour chaque projet.
Cela a été classé plusieurs fois sur Connect, le site de rapports de bogues de la communauté de Microsoft. Pour votre information, je pense que ce bogue affecte Visual Studio depuis 2003 et qu’il a été corrigé après RTM à chaque fois. :( L'une des références est la suivante:
Je suggèrerais de télécharger Process Explorer pour savoir exactement quel processus verrouille le fichier. On peut le trouver à:
http://technet.Microsoft.com/en-us/sysinternals/bb896653.aspx
Ceci est plutôt généralement causé par Avast.
Je peux généralement exécuter mes projets dans Release de toute façon, mais lors de l'exécution du débogage, cela échouerait assez régulièrement.
Je viens d'ajouter une exclusion pour mon dossier de projets et le problème semble disparaître. Je suppose que cela pourrait aussi être causé par un autre logiciel antivirus.
Pour moi, cela était dû à une invite de commande ouverte dans le dossier ciblé (C:\users\username\source\repos\project\project\bin\debug\app.publish).
Vous ne savez pas pourquoi le débogage nécessite un accès au dossier de publication, mais la fermeture de la fenêtre de commande a résolu le problème pour moi.
Renommer les fichiers .exe et .pub a fonctionné pour moi, mais vraiment fastidieux. Je suis également confronté au problème que je ne pouvais pas éditer pendant une session de débogage. Enfin, je suis allé à la page Paramètres de sécurité avancés, selon:
Je désélectionne puis re-sélectionne la case "Activer les paramètres de sécurité ClickOnce". Cela fait quelques jours que ça ne pose aucun problème ....
Si rien de ce qui précède ne fonctionne et que vous développez une application console:
Essayez de taper n'importe quel caractère dans Program.cs, puis supprimez-le. Je ne sais pas pourquoi cela fonctionne, mais cela semble résoudre le problème 'Impossible de copier' à chaque fois.
Lorsque j'ai été confronté à un problème similaire, la seule chose qui semblait fonctionner était:
- Cliquez avec le bouton droit sur le projet, accédez à Paramètres et assurez-vous que les versions Debug et Release ciblent les mêmes paramètres ou que les paramètres que l'application essaie de charger ou de sauvegarder ont été définis.
- Suppression du dossier C:\Users (YourUserAccount)\AppData\Local (YourAppName).
- Assurez-vous qu'aucun fichier que j'ai eu là-bas n'a été considéré comme "bloqué". En cliquant avec le bouton droit de la souris sur les fichiers inclus dans mon projet, je me suis rendu compte qu'une icône était bloquée et considérée comme mauvaise parce qu'elle avait été téléchargée à partir d'Internet. Je devais cliquer sur le bouton Débloquer (par exemple, consultez ceci: http://devierkoeden.com/Images/Articles/Dynamicweb/CustomModules/Part1/BlockedFiles.png - "Ce fichier provient d'un autre ordinateur et peut être bloqué pour aider à protéger cet ordinateur. ").
L'ajout du fichier ".exe" du dossier de débogage aux exclusions de mon anti-virus m'a vraiment aidé.
Aucune des autres réponses n'a fonctionné pour moi mais la fermeture de tous les onglets ouverts dans Visual Studio semble avoir résolu le problème.
J'ai essayé plusieurs solutions que vous avez fournies, mais parfois je reçois toujours cette erreur. Je suis convaincu que mon processus ne fonctionne pas et lorsque j'essaie de supprimer le fichier exécutable avec Internet Explorer, il est supprimé de la liste des fichiers, mais j'appuie sur F5 et le tour est joué, le fichier est de retour. Il n'a pas été supprimé du tout.
Mais si je supprime le fichier via TotalCommander, le fichier exe est réellement supprimé et je peux construire le projet avec succès.
J'utilise Windows 7 x64 et Total Commander 7.56a 32 bits.
Pour les services Windows utilisant WCF, j'ai terminé le processus d'hôte WFC et cela a fonctionné. Je déteste quand cela se produit, et cela se produit parfois de manière aléatoire.
Faites les choses simples en premier.
Vérifiez que cette partie de votre solution n'est pas verrouillée par un processus en cours d'exécution.
Par exemple, j'ai exécuté "InstallUtil 'sur mon service Windows (que je teste normalement à partir d'une console).
Cela a bloqué certaines de mes dll dans le dossier bin du projet de service Windows . Lorsque j'ai reconstruit, j'ai eu l'exception dans ce problème.
J'ai arrêté le service Windows, reconstruit et cela a réussi.
Vérifiez le Gestionnaire des tâches Windows pour votre application avant de suivre l'une des étapes avancées de ce problème.
Alors, quand vous entendez des pas, pensez aux chevaux, pas aux zèbres! (d'un ami étudiant en médecine)
Si quelqu'un essaie de résoudre ce problème en essayant de déboguer un test d'unité ou d'exécuter un test d'unité, je devais tuer les deux processus suivants pour pouvoir publier le fichier:
Je sais que la question est très ancienne, mais j'ai récemment rencontré l'erreur «Je ne peux pas copier d'objet en bin» dans VS 2012. Chaque fois que j'essayais de reconstruire un certain projet, je recevais le message. La seule solution consistait à effectuer un nettoyage avant chaque reconstruction.
Après de longues recherches, il apparaît que l'un de mes fichiers contenait une déclaration d'avertissement de pragma incomplète qui n'empêchait pas la compilation, mais qui empêchait VS de garder le (s) fichier (s) verrouillé (s).
En ce qui me concerne, j’avais les informations suivantes en haut du fichier:
#pragma warning(
C'est tout. J'imagine que j'essayais de faire quelque chose il y a quelque temps, que j'étais distrait et que je n'avais jamais terminé le processus, mais les avertissements du système de contrôle concernant cette ligne particulière ont été perdus. Finalement, j'ai remarqué l'avertissement, supprimé la ligne et reconstruit à chaque fois depuis.
J'ai eu le même problème. Il a dit ne pouvait pas copier de bin\debug à obj .....
Quand j'ai construit le projet Web, j'ai trouvé que mes dll étaient toutes dans le dossier bin et non dans bin\debug. Au cours de la publication, vs recherchait des fichiers dans bin\debug. J'ai donc ouvert le fichier de projet Web dans l'éditeur et recherché 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 publié à nouveau. Cette fois, vs a été en mesure de trouver toutes les dll dans le dossier bin et la publication a réussi.
Je ne sais pas du tout comment ce chemin a été modifié dans le fichier de projet Web.
J'ai passé plus de 5 heures à déboguer ceci et j'ai finalement trouvé la solution par moi-même.
C'est la bonne réponse .
[Résolu] Impossible de copier le fichier exe d'obj\debug vers bin\debug:
J'approche que vous obtenez cette erreur alors que vous essayiez d'exécuter deux fenêtres l'une après l'autre, par exemple en chargeant une fiche puis après parfois, celle-ci disparaîtra automatiquement et la deuxième sera chargée à l'écran.
Fondamentalement, vous devez fermer votre premier formulaire qui s'exécute en arrière-plan et la principale raison de cette erreur.
Pour fermer le premier formulaire, vous devez ajouter ces deux lignes de code dans le deuxième gestionnaire d'événements de chargement de formulaire.
Form1 form = new Form1();
form.Close();
Cela résoudra parfaitement l'erreur.
La réactivation du service Application Application de Windows a corrigé ce type de problèmes.
Voir les liens suivants:
- Autorisations de fichier de sortie Visual Studio?
- Dans quelles circonstances le processus système (PID 4) conserve-t-il un descripteur de fichier ouvert?
J'ai eu le problème avec Visual Studio 2008, 2010 et 2013 avec Windows 7 64 bits.
J'ai trouvé avec VS2013 que j'obtiens cette erreur régulièrement. Une solution qui semble fonctionner correctement consiste à exécuter une solution de reconstruction avant d'essayer d'exécuter l'application. J'ai constaté que l'exécution d'un CLEAN fonctionne parfois, mais la solution de reconstruction semble fonctionner de manière plus cohérente.
Cela aide pour moi après avoir retiré le drapeau en lecture seule du répertoire bin . http://www.thewindowsclub.com/error-0x80080015-windows-defender-activation-requires-display-name
- Définir un autre projet comme démarrage
- Construire le projet (le projet non problématique s'affichera)
- Allez dans le dossier problématique
bin\debug - Renommez
myservice.vshost.exeenmyservice.exe
Ma solution n'a rien à voir avec les versions, les processus en cours de verrouillage, le redémarrage ou la suppression de fichiers.
Le problème était en fait dû à l'échec de la construction et au fait de ne pas donner l'erreur correcte . Le problème réel é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 modifié la portée de "a" en dehors de la fonction, ou ne pas utiliser "a" après Task.Factory.StartNew();, j'ai été en mesure de construire à nouveau.
Cela s'est produit lors de l'utilisation de VS2012 Update 4 sur Windows7x64 sp1.
Message d'erreur:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets (3390,5): erreur MSB3030: Impossible de copier le fichier "obj\x86\Debug\xxx.exe" car il n'a pas été trouvé.