La construction de Visual Studio échoue : impossible de copier le fichier exe à partir de l'obj. \debug à la poubelle \debug

Question

Mise à jour : Un exemple de projet reproduisant ce bogue peut être trouvé ici à Microsoft Connect . J'ai également testé et vérifié que la solution donnée dans le document 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 autre problème (qui fait l'objet d'une question distincte).

---

Il s'agit d'une question déjà 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é, alors je dois essayer de poser une nouvelle question.

Scénario : J'ai une application Windows Forms simple (C#, .NET 4.0, Visual Studio 2010). Elle possède quelques formulaires de base dont la plupart des autres formulaires héritent, elle utilise Entity Framework (et les classes POCO) pour l'accès aux bases de données. Rien d'extraordinaire, pas de multithreading ou autre.

Problème : Tout allait bien pendant un certain temps. Puis, tout à coup, Visual Studio n'a pas réussi à construire l'application alors que j'étais sur le point de la lancer. J'ai reçu l'avertissement suivant "Impossible de supprimer le fichier '...bin \Debug\ Nom du projet].exe'. Accès au chemin '...bin \Debug\ [Nom du projet].exe' est refusé." et l'erreur "Impossible de copier le fichier 'obj \x86\Debug\ [Nom du projet].exe" en "bin". \Debug\ Nom du projet].exe'. Le processus ne peut pas accéder au fichier 'bin \Debug\ [Nom du projet].exe' parce qu'il est utilisé par un autre processus". (J'obtiens à la fois l'avertissement et l'erreur lors de l'exécution de Rebuild, mais seulement l'erreur lors de l'exécution de Build - je ne pense pas que cela soit pertinent ?)

Je comprends parfaitement ce que disent les messages d'avertissement et d'erreur : Visual Studio essaie manifestement d'écraser le fichier exe tout en le verrouillant pour une raison quelconque. Cependant, cela ne m'aide pas à trouver une solution au problème... La seule chose que j'ai trouvé qui fonctionne est de fermer Visual Studio et de le relancer. La construction et le lancement fonctionnent alors, jusqu'à ce que je fasse un changement dans certains des formulaires, puis j'ai à nouveau le même problème et je dois redémarrer... C'est assez frustrant !

Comme je l'ai mentionné plus haut, ce problème semble être connu, et de nombreuses solutions ont été proposées. Je vais simplement énumérer ce que j'ai déjà essayé ici, pour que les gens sachent ce qu'il faut éviter :

• Créer une nouvelle solution propre et copier simplement les fichiers de l'ancienne solution.

• Ajout de ce qui suit à 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"

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

   <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>

Cependant, aucune d'entre elles n'a fonctionné pour moi, alors vous pouvez 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 ! S'agit-il d'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 autre, et si oui, comment puis-je le découvrir ?

Toute suggestion est la bienvenue :)

Mise à jour : Comme mentionné dans le commentaire ci-dessous, j'ai également vérifié à l'aide de Process Explorer qu'il s'agit bien de est Visual Studio qui verrouille le fichier.

Answer 1

Cela va vous paraître stupide, mais j'ai essayé toutes ces solutions, en utilisant VS2010 sur Windows 7. Aucune d'entre elles n'a fonctionné, à l'exception du renommage et de la construction, qui étaient pour le moins TRÈS fastidieux. Finalement, j'ai trouvé le coupable, et je trouve cela difficile à 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 à la version 2.0.0.0 a permis de rétablir la situation. Je ne sais pas si c'est une spécificité de Windows 7 (je ne l'utilise que depuis 3-4 semaines), ou si c'est aléatoire, ou quoi, mais cela a réglé le problème pour moi. Je suppose que VS gardait un œil sur chaque fichier qu'il générait, afin de savoir 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 s'arrache les cheveux, essayez-le.

Answer 2

Comme je n'ai pas reçu d'autres commentaires sur cette question, j'ai pensé que je pourrais simplement partager ce qui a été ma solution :

Comme l'a suggéré Barry dans un commentaire de l'article original, il est possible de renommer manuellement le fichier d'aide à l'écriture. '...bin \Debug Nom du projet].exe à quelque chose d'autre (par exemple '[Nom du projet]1.exe'. ) est une solution de contournement (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 aussi le renommage...). Ce n'est pas une bonne solution, mais c'est raisonnablement rapide (du moins après l'avoir fait plusieurs fois, cela devient presque une routine), et en tout cas beaucoup plus rapide que de redémarrer Visual Studio, ce que j'ai fait au début.

Au cas où quelqu'un se poserait la question, je pourrais aussi ajouter que je ne vois ce problème que de façon semi-aléatoire. Il se produit généralement après que j'ai effectué des modifications dans le mode de conception d'un formulaire (mais pas toujours). Il ne se produit généralement pas si je ne modifie que le code de la logique d'entreprise ou le code non lié à l'aspect visuel (mais parfois si...). Frustrant en effet, mais au moins j'ai un hack qui fonctionne pour moi - espérons juste que mon prochain projet ne sera pas confronté à ce problème aussi...

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

Answer 3

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

Answer 4

J'ai le même problème (MSB3021) avec un projet WPF dans VS2008 (sur 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, le fichier exe se débloque de lui-même et je peux relancer l'application. Mais une pause aussi longue me met en colère. La seule chose qui m'a vraiment aidé a été de lancer VS en tant qu'administrateur.

Answer 5

J'ai essayé toutes les autres suggestions dans les réponses ici, aucune n'a fonctionné. Finalement, j'ai utilisé Process Monitor pour découvrir que mon .exe que VS2010 ne parvenait pas à construire était verrouillé par le processus System (PID=4). En cherchant dans SO des situations impliquant ceci, j'ai trouvé ce 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'ennuis sont terminés.