Ugh, c'est un vieux problème, quelque chose qui apparaît toujours dans Visual Studio de temps en temps. Cela m'a mordu plusieurs fois et j'ai perdu des heures à redémarrer et à me battre avec VS. Je suis sûr que cela a été discuté ici sur SO plus d'une fois. On en a également parlé sur les forums MSDN. Il n'y a pas de solution réelle, mais il existe quelques solutions de contournement. Commencez vos recherches ici .
Ce qui se passe, c'est que VS acquiert un verrou sur un fichier et ne le libère pas. Ironiquement, ce verrou empêche VS lui-même de supprimer le fichier afin qu'il puisse le recréer lorsque vous reconstruisez l'application. La seule solution apparente consiste à fermer et redémarrer VS afin qu'il libère le verrou sur le fichier.
Ma solution originale de contournement était d'ouvrir le dossier bin / Debug et de renommer l'exécutable. Vous ne pouvez pas le supprimer s'il est verrouillé, mais vous pouvez le renommer. Vous pouvez donc simplement ajouter un numéro à la fin ou quelque chose, ce qui vous permet de continuer à travailler sans avoir à fermer toutes vos fenêtres et à attendre que VS redémarre. Certaines personnes ont même automatisé cela en utilisant un événement de pré-construction pour ajouter une chaîne aléatoire à la fin de l'ancien nom de fichier de sortie. Oui, c'est un hack géant , mais ce problème devient tellement frustrant et débilitant que vous ferez n'importe quoi.
J'ai appris plus tard, après un peu plus d'expérimentation, que le problème ne semble surgir que lorsque vous construisez le projet avec l'un des concepteurs ouvert. Donc, la solution qui a fonctionné pour moi à long terme et qui m'a empêché de faire face à l'une de ces erreurs stupides à nouveau est de s'assurer que je ferme toujours toutes les fenêtres de concepteur avant de créer un projet WinForms. Oui, cela aussi est quelque peu gênant, mais cela ne vaut pas le coup de devoir redémarrer VS deux fois par heure ou plus.
Je suppose que cela s'applique également à WPF, bien que je ne l'utilise pas et que je n'y ai pas personnellement rencontré le problème.
Je n'ai pas encore essayé de le reproduire sur VS 2012 RC. Je ne sais pas si cela a encore été corrigé ou non. Mais mon expérience jusqu'à présent a été qu'il parvient toujours à apparaître même après que Microsoft a prétendu l'avoir réparé. Il est toujours là dans VS 2010 SP1. Je ne dis pas que leurs programmeurs sont des idiots qui ne savent pas ce qu'ils font, bien sûr. Je pense qu'il y a juste plusieurs causes pour le bogue et / ou qu'il est très difficile à reproduire de manière fiable dans un laboratoire. C'est la même raison pour laquelle je n'ai pas personnellement déposé de rapport de bogue à ce sujet (bien que j'aie +1 d'autres personnes), parce que je n'arrive pas à le reproduire de manière fiable, un peu comme l'Abominable Snowman.
<fin de coup de gueule qui ne vise personne en particulier>