Ugh, c'est un vieux problème, quelque chose qui apparaît encore dans Visual Studio de temps en temps. Il m'a mordu quelques fois et j'ai perdu des heures à redémarrer et à me battre avec VS. Je suis sûr qu'il a été discuté ici sur SO plus d'une fois. Il a également été abordé sur les forums MSDN. Il n'y a pas de solution réelle, mais il y a 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 de pouvoir le recréer lorsque vous reconstruisez l'application. Le seul problème apparent La solution consiste à fermer et à redémarrer VS pour qu'il libère le verrou sur le fichier.
Ma solution originale consistait à ouvrir le dossier bin/Debug et à renommer l'exécutable. Vous ne pouvez pas supprimer s'il est verrouillé, mais vous pouvez le renommer. Vous pouvez donc ajouter un numéro à la fin ou autre 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é cette opération 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 géant mais ce problème devient si frustrant et débilitant que vous êtes prêt à tout.
J'ai appris par la suite, après un peu plus d'expérimentation, que le problème ne semble apparaître que lorsque vous construisez le projet avec l'un des concepteurs ouverts. Ainsi, la solution qui a fonctionné pour moi à long terme et qui m'a empêché d'avoir à nouveau affaire à une de ces erreurs stupides est de m'assurer que je ferme toujours toutes les fenêtres des concepteurs avant de construire un projet WinForms. Oui, cela aussi est un peu gênant, mais c'est bien mieux que d'avoir à 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'aie jamais rencontré ce problème.
Je n'ai pas non plus encore essayé de le reproduire sur VS 2012 RC. Je ne sais pas si le problème a été corrigé ou non. Mais mon expérience jusqu'à présent a été qu'il arrive toujours à apparaître même après que Microsoft ait prétendu l'avoir corrigé. Il est toujours présent 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 simplement plusieurs causes à ce bug et/ou qu'il est très difficile à reproduire de manière fiable en laboratoire. C'est la même raison pour laquelle je n'ai pas personnellement rempli de rapport de bogue à ce sujet (bien que j'aie fait un +1 à d'autres), parce que je n'arrive pas à le reproduire de manière fiable, un peu comme l'abominable homme des neiges.
<pour en finir avec cette diatribe qui ne s'adresse à personne en particulier>
