2010-08-18 5 views
4

Vous vous demandez si quelqu'un a trouvé une solution à ce bogue de 2010. J'ai un projet qui s'est bien construit dans Visual Studio 2008 qui ne sera pas construit en 2010 car Visual Studio reste sur la dll après que l'application soit exécutée UNIQUEMENT si une fenêtre de concepteur est ouverte. J'ai créé un projet vraiment léger qui montre ce problème. Si vous créez une application, créez une DLL lib. Mettez un formulaire dans la DLL, ouvrez le formulaire en mode Création, puis exécutez l'application. Il fonctionnera bien, puis fermez l'application, allez à l'affichage du code en mode design, et changez le code (je viens de renommer une seule variable) puis essayez de recompiler vous obtenez ce qui suit:Bogue de Visual Studio 2010 Designer: Impossible de copier depuis obj debug vers bin debug

Erreur 1 Impossible copier le fichier "obj \ Debug \ customlib.dll" vers "build \ debug \ customlib.dll". Le processus ne peut pas accéder au fichier 'build \ debug \ Customlib.dll' car il est utilisé par un autre processus.

Si vous exécutez Process Explorer et recherchez la DLL, le seul processus qui contient la DLL est devenv.exe !!!

J'ai fait beaucoup de recherches sur ce problème et j'ai trouvé des problèmes similaires avec les anciennes versions de Dev Studio où les gens pouvaient simplement add a pre-step déplacer la DLL verrouillée vers un autre nom (.locked) et construire. Eh bien cela fonctionne la première fois, mais la prochaine fois que vous exécutez puis modifier vous êtes verrouillé à la fois la DLL actuelle et celle que vous avez déplacé à .locked, donc à moins que je suis prêt à ajouter du code pour générer un nom pour la DLL verrouillée , cela ne fonctionnera pas pour moi (je ne veux pas que la taille de mon répertoire de débogage croisse avec des fichiers jamais supprimés.)

J'ai seulement trouvé une solution de contournement et si vous êtes dans ce même bateau c'est ce que je dois faire éditer et exécuter. Je m'assure que CHAQUE fenêtre de vue de conception est fermée AVANT d'exécuter mon projet dans le débogueur. Si vous fermez toutes les fenêtres d'affichage de conception ouverte devenv.exe ne tiendra pas la DLL.

Est-ce que quelqu'un a une meilleure solution à ce problème?

+0

C'est ennuyeux et ça se passe dans divers VS depuis aussi longtemps que je me souvienne. Essayez de créer un projet de reproduction minimal et soumettez-le à Microsoft Connect avec autant d'informations que possible. Peut-être que vous en avez trouvé un qu'ils peuvent réparer. –

+0

Excellente suggestion, je viens d'ajouter un bug, laisse voir ce qui en sort. –

+2

Voici un lien vers le problème dans MS Connect (https://connect.microsoft.com/VisualStudio/feedback/details/587281/vsual-studio-2010-designer-bug-unable-to-copy-from-obj-debug -to-bin-debug) Si vous avez le même problème, cliquez sur le bouton "Je peux repro". Je pense que plus il y a de gens qui le font, plus il y a de chances que cela soit réparé. –

Répondre

3

Je ne suis pas sûr que cela fonctionnera pour vous ou non, mais this similar question si vous avez cette ligne AssemblyInfo.cs:

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

changer à:

[assembly: AssemblyVersion("2.0.0.0")] 

résoudra ceci est.

Le module complémentaire Visual Studio "VSCommands" prétend avoir un correctif pour ce problème. Je ne l'ai pas encore testé, mais il prétend aussi avoir un en IDE tracker réputation qui me intrigue :)

Votre « designer Fermer avant le débogage » solution semble fonctionner pour moi (jusqu'à présent) , pour lequel je suis très reconnaissant. Il commençait à arriver à l'étape où une grande partie de ma journée a été passée dans le flux de travail suivant ...

  1. F5

  2. juron fort

  3. ALT F4

  4. WIN

  5. attend avec impatience ...

  6. F5
+0

Je dois avoir généré des numéros de version afin que la solution de contournement ne résout pas mon problème. J'étais avec vous sur le flux de travail et je faisais exactement la même chose. Merci d'avoir répondu. –

1

J'ai eu les mêmes problèmes depuis longtemps et puis tout à coup ils ont disparu. J'ai réalisé que la source des problèmes était l'initialisation du code dans les constructeurs de services WCF et les contrôles WPF. Après avoir nettoyé les constructeurs de toutes les dépendances à d'autres assemblées, tout s'est bien passé. Donc, ma suggestion est la suivante: Nettoyez vos constructeurs.

Dans WPF, il est possible que l'insertion:

if (DesignerProperties.GetIsInDesignMode(this)) return; 

ou similaire aura le même effet.

+0

Ce problème se pose dans Forms et non dans WPF, bien que cela se passe aussi dans nos projets WPF. Je vais essayer. Merci. –

Questions connexes