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

Mise à jour: 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 avez 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’ici ne m’a aidé, alors je dois juste essayer de poser une nouvelle question.

Scénario: J’ai une simple application Windows Forms (C #, .NET 4.0, Visual Studio 2010). Il a deux formes de base dont la plupart des autres formes héritent, il utilise Entity Framework (et les classes POCO) pour accéder à la firebase database. Rien de compliqué, pas de multi-threading ou quoi que ce soit.

Problème: Tout allait bien pendant un moment. Puis, tout à coup, Visual Studio n’a pas réussi à se lancer dans le lancement de l’application. J’ai reçu l’avertissement “Impossible de supprimer le fichier ‘… bin \ Debug \ [NomProjet] .exe’. L’access au chemin ‘… bin \ Debug \ [NomProjet] .exe’ est refusé.” et l’erreur “Impossible de copier le fichier ‘obj \ x86 \ Debug \ [NomProjet] .exe’ dans ‘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.” (J’obtiens à 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 Build – cela ne semble pas pertinent?)

Je comprends parfaitement ce que dit le message d’avertissement et d’erreur: Visual Studio essaie de toute évidence d’écraser le fichier exe alors qu’il a le même verrou pour quelque raison que ce soit. Cependant, cela ne m’aide pas à trouver une solution au problème … La seule chose que j’ai trouvé de travail est d’arrêter Visual Studio et de le redémarrer. Construire et lancer fonctionne alors, jusqu’à ce que je modifie certains des formulaires, puis j’ai à nouveau le même problème et je dois redémarrer … Très frustrant!

Comme je l’ai mentionné ci-dessus, cela semble être un problème connu, il y a donc beaucoup de 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éer une nouvelle solution propre et copier les fichiers de l’ancienne solution.
  • Ajout des éléments suivants à l’événement de pré-construction du projet:

    if exist "$(TargetPath).locked" del "$(TargetPath).locked" if not exist "$(TargetPath).locked" if exist "$(TargetPath)" move "$(TargetPath)" "$(TargetPath).locked" 
  • Ajout des éléments suivants aux propriétés du projet (fichier .csproj):

     true 

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ù regarder, alors j’espère que quelqu’un a quelque chose à me donner! Est-ce un bogue dans VS, et si oui, y a-t-il un correctif? Ou ai-je fait quelque chose de mal, est-ce que j’ai une référence circulaire ou similaire, et si oui comment pourrais-je le découvrir?

Toutes les suggestions sont très appréciées 🙂

Mise à jour: Comme mentionné dans le commentaire ci-dessous, j’ai également vérifié en utilisant Process Explorer que c’est réellement Visual Studio qui verrouille le fichier.

Cela va sembler stupide, mais j’ai essayé toutes ces solutions, en utilisant VS2010 sur Windows 7. Aucun d’entre eux ne fonctionnait sauf le changement de nom et la construction, ce qui était TRÈS fastidieux. 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 permis aux choses de fonctionner à nouveau. 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 a été corrigé pour moi. Je suppose que VS gardait une poignée sur chaque fichier généré, donc il savait 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 se tire les cheveux, essayez-le.

J’ai trouvé une solution simple, il suffit de désactiver les services d’indexation Windows pour le dossier de projet et les sous-dossiers

Comme je n’ai plus eu de retour sur cette question, j’ai pensé partager mon expérience:

Comme suggéré par Barry dans un commentaire à la publication originale, renommer manuellement le ‘… bin \ Debug [NomProjet] .exe’ pour quelque chose d’autre (par exemple, ‘[NomProjet] 1.exe’ ) est un contournement (I ‘ Je n’ai cependant pas le droit de supprimer le fichier moi-même, et je dois dire que je trouve ça un peu bizarre car on croirait que le même verrou empêchant la suppression empêcherait également de renommer …). Ce n’est pas une bonne solution, mais elle est rapide (au moins une fois que vous l’avez fait, cela devient presque une routine) et au moins plus rapide que de redémarrer Visual Studio, ce que j’ai fait au début.

Si quelqu’un se demande, je pourrais aussi append que je ne vois ce problème que de manière semi-aléatoire. Cela se produit généralement après avoir apporté des modifications au 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 associé non visuel (mais parfois…). Frustrant en effet, mais au moins j’ai un hack qui fonctionne pour moi – espérons que mon prochain projet ne sera pas confronté à ce problème aussi …

@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 relancer 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 relancer l’application à nouveau. Mais une si longue pause me met en colère. La seule chose qui m’a vraiment aidé était de lancer VS en tant qu’administrateur.

Lorsque je suis tombé sur ce problème, il est lié au fait que le projet que je tente de générer est défini comme projet de démarrage dans la solution, ce qui rend le fichier .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 vous laissera 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 mon fichier .exe que VS2010 ne parvenait pas à construire était verrouillé par le processus système (PID = 4). La recherche de SO pour des situations impliquant ceci a donné cette réponse.

En 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’avais aussi un problème très similaire à celui-ci et j’ai trouvé que la raison en était que le dossier bin \ debug était disponible sous la forme d’un dossier partagé sous VMware et VMware, Explorer sous l’invité VM ou même d’un anti-virus. programme sous l’invité (bien que je ne pense pas en avoir un installé) tenait un handle vers le (s) fichier (s).

Désactiver “Activer le processus d’hébergement Visual Studio” Paramètres de débogage du projet

SI VOTRE PROBLÈME N’EST PAS 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 au gestionnaire de tâches de Windows (Ctrl + Shift + Esc), trouvez le nom de votre application et forcez-le à fermer par Endprocces.

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

Ma solution consistait à désactiver le processus d’hébergement de Visual Studio.

Pour les personnes intéressées, j’ai attaché une trace de poignée pour la poignée en question:

 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::`ssortingng'+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::`ssortingng'+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::`ssortingng'+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::`ssortingng'+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::`ssortingng'+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::`ssortingng'+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::`ssortingng'+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 Atsortingbutes 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, 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 tabs que j’avais ouverts dans VS, fermé VS, puis assuré de tuer tous les processus MSBuild dans taskmanager. 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 pour ce problème. Après avoir effectué quelques refactoring 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 de la solution comme prévu.

Ce studio visuel trompeur pense qu’il pourrait construire des projets simultanément, créant ainsi les verrous de fichiers.

EDIT: Cela s’est produit à plusieurs occasions, même récemment avec VS2012 et il résout le problème une fois que j’ai défini l’ordre de construction aux dépendances correctes, éliminé tous les processus msbuild exécutés par VS, puis 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 provoquer ceci est de refactoriser un projet tel qu’il repose sur un autre projet de la solution qui ne faisait pas référence à la dernière version. Cela semble parfois confondre VS et il ne met pas à jour l’ordre de construction.

Pour vérifier l’ordre de génération: Cliquez avec le bouton droit de la souris sur la solution dans l’Explorateur de solutions et sélectionnez “Ordre de génération de projet …” et vérifiez que les dépendances sont correctement notées pour chaque projet.

Redémarrer 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 je désactivais l’antivirus résolu.

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

Cela a été déposé à plusieurs resockets sur Connect, le site de rapports de bogues de la communauté Microsoft. Pour ma part, je pense que ce bogue a affecté Visual Studio depuis 2003 et qu’il a été corrigé après chaque RTM. 🙁 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 aucun des éléments ci-dessus ne fonctionne, et que vous développez une application console:

Essayez de taper un caractère dans Program.cs, puis supprimez-le. Je n’ai aucune idée de la raison pour laquelle cela fonctionne, mais il semble résoudre le problème de la copie impossible à chaque fois.

Ceci est plutôt causé par Avast.

Je peux généralement lancer mes projets dans Release, mais en cas de débogage, cela échoue régulièrement.

Je viens d’append une exclusion pour mon dossier de projets et le problème semble disparaître. Je suppose que cela pourrait également être causé par d’autres logiciels antivirus.

Renommer le fichier .exe et .pub a fonctionné pour moi, mais vraiment fastidieux. Je suis également confronté au problème que je ne pouvais pas modifier lors d’une session de débogage. Enfin, je suis allé à la page des parameters 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-%22.NETFRAMEWORK%2cVERSION % 3dV4.0% 22% 29 & rd = true

Je désélectionne puis re-sélectionne la case à cocher “Activer les parameters de sécurité ClickOnce”. Cela ne pose aucun problème depuis quelques jours maintenant ….

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 ).

Vous ne savez pas pourquoi DEBUGGING nécessite un access au dossier de publication, mais la fermeture de la fenêtre de commande a résolu le problème pour moi.

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 que lorsque je tente 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é. Il n’a pas été supprimé du tout.

Mais si je supprime le fichier via TotalCommander, le fichier exe est effectivement supprimé et je peux créer le projet avec succès.

J’utilise Windows 7 x64 et total commandant 7.56a 32 bits.

Aucune des autres réponses n’a fonctionné pour moi, mais la fermeture de tous les tabs 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é le message d’erreur “impossible à copier depuis obj to 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 beaucoup de recherches, il s’est avéré que j’avais un message d’avertissement de pragma incomplet dans l’un de mes fichiers qui n’empêchait pas la compilation de réussir, mais confondait VS avec le fait de garder le ou les fichiers verrouillés.

Dans mon cas, j’avais les éléments suivants en haut du fichier:

 #pragma warning( 

C’est tout. Je suppose que j’essayais de faire quelque chose il y a quelque temps et que j’étais distrait et que je n’avais jamais fini le processus, mais les avertissements de VS concernant cette ligne particulière ont été perdus dans le mélange. Finalement, j’ai remarqué l’avertissement, enlevé la ligne et reconstruit le travail à chaque fois depuis.

Faites les choses simples en premier.

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 depuis une console).

Cela a verrouillé certaines de mes DLL dans le dossier bin du projet de service Windows. Quand j’ai fait une reconstruction, j’ai eu l’exception dans ce numéro.

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

Consultez le Gestionnaire des tâches Windows pour votre application avant de procéder aux étapes préalables de ce problème.

Alors, quand vous entendez des pas, pensez aux chevaux, pas aux zèbres! (de l’ami étudiant en médecine)

Lorsque j’ai fait face à un problème similaire, la seule chose qui semblait fonctionner était:

  • Cliquez avec le bouton droit de la souris sur le projet, accédez à Paramètres et assurez-vous que les versions Debug et Release ciblent les mêmes parameters ou que les parameters de l’application tentent d’être chargés ou enregistrés.
  • Suppression du dossier C: \ Users (YourUserAccount) \ AppData \ Local (YourAppName).
  • En veillant à ce qu’aucun fichier que j’avais dedans ne soit 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 incorrecte 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 vous 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 ça quand ça arrive, et ça arrive parfois au hasard.

Ma solution n’a rien à voir avec les versions, les processus en cours de locking, le redémarrage ou la suppression de fichiers.

Le problème était en réalité dû à l’échec de la construction 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 modifié la scope 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 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 trouvé que l’exécution d’un CLEAN 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 …..

Lorsque j’ai construit un projet Web, j’ai trouvé que mon dll était dans le dossier bin et non dans bin \ debug. Pendant la publication vs cherchait 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 sous le nom bin \ debug \ mylibrary.dll. J’ai supprimé tous les \ debug du chemin et publié à nouveau. Cette fois, vs était capable de trouver tout le dll dans le dossier bin et publier 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 à le déboguer et j’ai finalement trouvé la solution par moi-même.

C’est la bonne réponse .

Cela m’aide après que je supprime l’indicateur de lecture seule du répertoire bin. http://www.thewindowsclub.com/error-0x80080015-windows-defender-activation-requires-display-name