La génération de Visual Studio échoue: impossible de copier le fichier exe de obj \ debug vers bin \ debug

Mise à jour: un exemple de projet reproduisant ce bogue est disponible 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 appartient à une question distincte).

C'est une question posée auparavant, à la fois ici sur Stack Overflow et dans d'autres endroits, mais aucune des suggestions que j'ai trouvées jusqu'à présent ne m'a aidé, donc je dois juste 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 formes de base dont la plupart des autres formes héritent, 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'a pas réussi à générer lorsque j'étais sur le point de lancer l'application. J'ai reçu l'avertissement "Impossible de supprimer le fichier '... bin \ Debug \ [ProjectName] .exe'. L'accès au chemin '... bin \ Debug \ [ProjectName] .exe' est refusé." et l'erreur «Impossible de copier le fichier« obj \ x86 \ Debug \ [ProjectName] .exe »vers« bin \ Debug \ [ProjectName] .exe ». Le processus ne peut pas accéder au fichier« bin \ Debug \ [ProjectName] .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 Rebuild, mais uniquement l'erreur lors de l'exécution de Build - vous ne pensez pas que cela soit pertinent?)

Je comprends parfaitement ce que dit l'avertissement et le message d'erreur: Visual Studio essaie évidemment d'écraser le fichier exe alors qu'il a en même temps un verrou dessus pour une raison quelconque. Cependant, cela ne m'aide pas à trouver une solution au problème ... La seule chose que j'ai trouvée fonctionne est d'arrêter Visual Studio et de le redémarrer. La construction et le lancement fonctionnent alors, jusqu'à ce que je modifie certains formulaires, puis j'ai à nouveau le même problème et je dois redémarrer ... Assez frustrant!

Comme je l'ai mentionné ci-dessus, cela semble être un problème connu, il existe donc de nombreuses solutions suggérées. Je vais simplement énumérer ce que j'ai déjà essayé ici, afin que les gens sachent quoi ignorer:

• Création d'une nouvelle solution propre et copiez simplement les fichiers de l'ancienne solution.

• Ajout de ce qui suit à l'événement suivant 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"
  

• Ajout de ce qui suit aux propriétés du projet (fichier .csproj):

  <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>

Cependant, aucun d'entre eux n'a fonctionné pour moi, vous pouvez donc probablement comprendre 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 bug dans VS, et si oui, y a-t-il un patch? 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 :)

Mise à jour: Comme mentionné dans le commentaire ci - dessous, je l' ai également vérifié avec l' Explorateur de processus qu'il fait est Visual Studio qui bloque le fichier.

Cela va sembler stupide, mais j'ai essayé toutes ces solutions, exécutant VS2010 sur Windows 7. Aucune d'entre elles n'a fonctionné, sauf le changement de nom et la construction, ce qui était TRÈS fastidieux pour le moins. Finalement, j'ai retrouvé le coupable et j'ai du mal à y croire. Mais j'utilisais le code suivant dans AssemblyInfo.cs ...

[assembly: AssemblyVersion("2.0.*")]

C'est assez courant, mais pour une raison quelconque, changer la version en 2.0.0.0 a fait fonctionner à nouveau les choses. Je ne sais pas si c'est une chose spécifique à Windows 7 (je ne l'utilise que depuis 3-4 semaines), ou si c'est aléatoire, ou quoi, mais ça l'a corrigé pour moi. Je suppose que VS gardait une poignée sur chaque fichier qu'il a généré, donc il saurait comment 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 tire également ses cheveux, essayez-le.

Étant donné que je n'ai plus reçu de commentaires sur ce problème, j'ai pensé partager ce qui s'est avéré être ma solution:

Comme l'a suggéré Barry dans un commentaire à l'article d'origine, renommer manuellement le '... bin \ Debug [ProjectName] .exe' en quelque chose d'autre (par exemple '[ProjectName] 1.exe' ) est une solution de contournement (I ' Je ne suis cependant pas autorisé à supprimer le fichier moi-même, et je dois dire que je trouve cela un peu bizarre car on pourrait croire que le même verrou empêchant la suppression empêcherait également de renommer ...). Ce n'est pas une bonne solution, mais c'est assez rapide (au moins après l'avoir fait plusieurs fois, cela devient presque une routine), et au moins beaucoup plus rapide que de redémarrer Visual Studio, ce que j'ai fait au début.

Au cas où quelqu'un se demanderait, je pourrais également ajouter que je ne vois ce problème que de manière semi-aléatoire. Cela se produit généralement après avoir effectué quelques modifications dans le mode de conception d'un formulaire (mais pas toujours). Cela ne se produit généralement pas si je ne modifie que le code de logique métier ou le code non visuel (mais parfois c'est le cas ...). Frustrant en effet, mais au moins j'ai un hack qui fonctionne pour moi - espérons juste que mon prochain projet ne sera pas aussi confronté à ce problème ...

@Barry: si vous souhaitez obtenir un crédit pour votre commentaire, n'hésitez pas à le poster comme réponse et je m'assurerai de l'accepter :)

J'ai trouvé une solution simple, désactivez simplement les services d'indexation Windows pour le dossier et les sous-dossiers du projet

J'ai le même problème (MSB3021) avec le projet WPF dans VS2008 (sous Windows 7 x32). Le problème apparaissant si j'essaye de relancer l'application trop rapidement après l'exécution précédente. Après quelques minutes d'exe-fichier 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é était d'exécuter VS en tant qu'administrateur.

Lorsque j'ai rencontré ce problème, cela est dû au fait que le projet que j'essaie de créer est défini comme projet de démarrage dans la solution rendant le .exe dans le dossier obj verrouillé (il apparaît également dans votre gestionnaire de tâches,) cliquez avec le bouton droit sur un autre projet dans votre solution et choisissez définir le projet de démarrage. Cela libérera le verrou, le supprimera du gestionnaire de tâches et devrait vous permettre de créer.

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 mon .exe que VS2010 ne parvenait pas à créer a été verrouillé par le processus système (PID = 4). La recherche de SO pour des situations impliquant cela a donné cette réponse.

En résumé: si vous avez désactivé le service Application Experience (comme je l'ai fait), réactivez-le et démarrez-le. Deux ans d'aggravation ont pris fin.

J'ai également 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, Explorer sous l'invité VM, ou peut-être même un anti-virus sous l'invité (bien que je ne pense pas en avoir installé un) tenait un handle vers le (s) fichier (s).

Désactivez «Activer le processus d'hébergement Visual Studio»

Je suggère 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

En utilisant Visual Studio, je n'ai jamais pu trouver un projet simple pour reproduire l'erreur.

Ma solution était de désactiver le processus d'hébergement Visual Studio.

Pour ceux intéressés, 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

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 dans le gestionnaire de tâches de Windows (Ctrl + Shift + Esc), trouvez le nom de votre application et forcez-la à fermer par Endprocces.

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 l'explorateur a indiqué que le fichier était utilisé par XAML UI Designer.

J'ai fermé tous les onglets que j'avais ouverts dans VS, fermé VS, puis je me suis assuré de tuer tous les processus MSBuild dans le gestionnaire de tâches. Enfin, après avoir redémarré VS, j'ai pu créer la solution.

et une autre cause possible:

J'ai remarqué une autre cause possible de ce problème. Après avoir effectué une refactorisation de code, déplacé 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 trompeur à penser qu'il pourrait construire certains projets simultanément, créant ainsi les verrous de fichiers.

EDIT: J'ai eu cela à quelques reprises même récemment avec VS2012 et il le corrige une fois que j'ai défini l'ordre de génération sur les dépendances correctes, tué tous les processus msbuild que VS a laissés en cours d'exécution, puis redémarrez VS. Je tue les processus msbuild juste pour être sûr, mais la fermeture de VS devrait aussi les tuer.

Ce que je fais habituellement pour provoquer cela est de refactoriser un projet de telle sorte qu'il s'appuie sur un autre projet de la solution qu'il ne faisait pas référence lors de la dernière génération. Cela semble parfois confondre VS et cela ne met pas à jour l'ordre de construction.

Pour vérifier l'ordre de génération: cliquez avec le bouton droit sur la solution dans l'explorateur de solutions et sélectionnez «Ordre de génération du projet ...» et vérifiez que les dépendances sont correctement notées pour chaque projet.

Redémarrez IIS - pourrait être un processus attaché au débogueur

Désactivez l'antivirus et essayez. J'étais également confronté à ce problème ... mais dans mon cas, l'antivirus bloquait mon application lorsque j'ai désactivé l'antivirus, il a été résolu.

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

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

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

Cela a été déposé plusieurs fois sur Connect, le site de rapport de bogues de la communauté Microsoft. Pour info, je crois que ce bogue a affligé 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

Faites d'abord les choses simples.

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

Par exemple, j'ai exécuté «InstallUtil» sur mon service Windows (que je teste normalement à partir d'une console).

Cela a verrouillé certaines de mes DLL dans le dossier bin du projet de service Windows. Lorsque j'ai fait une reconstruction, j'ai eu l'exception dans ce problème.

J'ai arrêté le service Windows, reconstruit et il a réussi.

Vérifiez le Gestionnaire des tâches de Windows pour votre application, avant d'effectuer l'une des étapes avancées de ce problème.

Alors, quand vous entendez des pas, pensez aux chevaux et non aux zèbres! (d'un ami étudiant en médecine)

J'ai eu le même problème. Il a dit qu'il ne pouvait pas copier de bin \ debug vers obj .....

Quand je construis un projet web, j'ai trouvé que mes dll étaient tous dans le dossier bin et non dans bin \ debug. Lors 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 d'accès et publié à nouveau. Cette fois, vs a pu trouver tous les fichiers dll dans le dossier bin et la publication a réussi.

Je n'ai aucune idée de la façon dont ce chemin a été modifié dans le fichier de projet Web.

J'ai passé plus de 5 heures à déboguer cela et j'ai finalement trouvé la solution par moi-même.

Ceci est la bonne réponse .

Si aucun des éléments ci-dessus 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.

Ceci est plutôt souvent causé par Avast.

Je peux généralement exécuter mes projets dans Release indépendamment, mais lors de l'exécution en débogage, il échouait assez régulièrement.

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

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 faire de modification lors d'une session de débogage. Enfin, je suis allé à la page Paramètres de sécurité avancés, 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- %% % 3dV4.0% 22% 29 & rd = true

Je désélectionne puis re-sélectionne la case "Activer les paramètres de sécurité ClickOnce". Cela fait maintenant quelques jours sans problème ....

Pour moi, cela était dû à l'ouverture d'une invite de commande dans le dossier cible (C:\users\username\source\repos\project\project\bin\debug\app.publish ).

Je ne sais 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.

Dans le cas où quelqu'un se heurte à cela en essayant de déboguer un test unitaire ou d'exécuter un test unitaire, j'ai dû tuer les deux processus suivants pour qu'il libère le fichier:

J'ai essayé plusieurs solutions que vous avez fournies, mais parfois je reçois toujours cette erreur. Je suis certain 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.

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.

Je sais que c'est une très vieille question, mais j'ai récemment rencontré l'erreur «impossible de copier de obj vers bin» dans VS 2012. Chaque fois que j'ai essayé de reconstruire un certain projet, j'ai reçu le message. La seule solution était de faire un nettoyage avant chaque reconstruction.

Après de nombreuses recherches, il s'est avéré que j'avais un avertissement de pragma incomplet dans l'un de mes fichiers qui n'a pas empêché la compilation de réussir, mais a quelque peu dérouté VS pour garder le ou les fichiers verrouillés.

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

#pragma warning(

C'est tout. Je suppose que j'essayais de faire quelque chose il y a quelque temps et que je me suis distrait et que je n'ai jamais terminé le processus, mais les avertissements VS concernant cette ligne particulière ont été perdus lors du shuffle. Finalement, j'ai remarqué l'avertissement, supprimé la ligne et reconstruit à chaque fois depuis.

Lorsque j'ai fait face à 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 de débogage et de version ciblent les mêmes paramètres ou contiennent les paramètres que l'application essaie de charger ou d'enregistrer.
• Suppression du dossier C: \ Users (YourUserAccount) \ AppData \ Local (YourAppName).
• S'assurer qu'aucun fichier que j'avais là-bas n'était considéré comme "Bloqué". En cliquant avec le bouton droit sur les fichiers inclus de mon projet, j'ai réalisé qu'une icône était en fait bloquée et considérée comme mauvaise car elle avait été téléchargée sur Internet. J'ai dû cliquer sur le bouton Débloquer (par exemple, vérifiez 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. ").

Pour les services Windows utilisant WCF, j'ai mis fin au processus hôte WFC et cela a fonctionné. Je déteste quand cela se produit, et cela arrive parfois au hasard.

Ma solution n'a rien à voir avec les versions, les processus étant verrouillés, le redémarrage ou la suppression de fichiers.

Le problème était en fait dû à l'échec de la génération et à l'absence d'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 changé la portée de "a" en dehors de la fonction, ou ne pas utiliser "a" après Task.Factory.StartNew(); , j'ai pu reconstruire.

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

J'ai trouvé avec VS2013 que j'obtiens régulièrement cette erreur. Quelque chose qui semble fonctionner assez bien consiste à exécuter une solution de reconstruction avant d'essayer d'exécuter l'application. J'ai trouvé que l'exécution d'un CLEAN fonctionne parfois, mais la solution de reconstruction semble fonctionner de manière plus cohérente.