2010-02-04 3 views
8

J'utilise VS2008, et j'ai un projet qui ne démarre pas lorsque j'appuie sur F5 ou lorsque je clique sur le petit triangle vert dans la barre d'outils. L'écran scintille une fois, comme si le projet allait fonctionner, mais ce n'est pas le cas. Le message de construction affirme que la génération a réussi, mais le projet ne démarre pas.Le projet ne démarre pas en mode débogage

Dans le Gestionnaire de configuration, ma 'Configuration de solution active:' est définie sur Débogage et dans la liste 'Contextes de projet', la colonne 'Configuration' de mon Projet est définie sur Débogage. Je les ai même échangés entre Déboguer et Relâcher, puis de nouveau sur Déboguer, sans aucun effet. Le projet que j'essaie de lancer est défini comme le «projet de démarrage» dans ma solution.

Si je vais dans le dossier \ bin \ Debug et que je clique deux fois sur le fichier .exe (qui indique l'horodatage approprié sur le fichier), mon application fonctionne correctement.

Des idées pour lesquelles je ne peux pas faire fonctionner l'idiot en mode debug?

EDIT:
C'est une application winforms.

Ma version de Visual Studio est 9.0.30729.1 SP

.NET Framework: Version 3.5 SP1

EDIT:

Cela peut être lié à TortoiseSVN. Je garde mon code source pour ce projet dans SVN. Quand je fais un checkout différent/nouveau dans TortoiseSVN, parfois le nouveau checkout permettra alors au projet de fonctionner. Je ne comprends pas la nature apparemment intermittente de ce problème.

EDIT:

Je ne sais pas si cette information est pertinente au problème, mais quand je fais une nouvelle caisse et ont une structure de dossier qui est moins profond (pas autant de dossiers imbriqués) que la caisse d'origine , J'ai l'impression d'avoir une meilleure chance que le projet tourne sans problème. Le problème n'avait rien à voir avec TortoiseSVN, voir ma réponse ci-dessous.

+0

Avez-vous essayé de mettre des points d'arrêt dans votre code de démarrage pour voir ce qui se passe? –

+0

@Bill W, Oui, j'ai essayé des points de rupture dans le code de démarrage. Ils ne sont jamais atteints. – Stewbob

+0

J'ai le même problème, mais légèrement différent. Il va comme ceci: 1) J'ouvre Visual Basic 2) Je peux déboguer une fois 3) Quand j'essaye de déboguer à nouveau, il indique "le dossier ne peut pas être accédé parce qu'il est employé par un autre processus" et arrête 4) débogage après, je reçois ce problème 5) Je redémarre VB. – nbura

Répondre

4

Il a exécuté un certain type de mise à jour de Windows sur mon ordinateur et cela a apparemment résolu le problème. Cela avait quelque chose à voir avec une exception System.Runtime.InteropServices.COMException et une erreur dans un 'Hébergement' .dll. Je ne sais pas pourquoi une DLL Hosting corrompue a eu un impact sur une application winforms, mais elle a corrigé le problème.

+0

Des choses étranges peuvent et arrivent trop souvent. Nous ne comprenons pas toujours pourquoi, mais il est bon d'être de nouveau opérationnel. :) –

0

Doit commencer avec les bases ... Avez-vous éliminé la possibilité d'un crash d'exécution avant que le formulaire principal est montré?

+1

L'exécutable s'exécute correctement. – Stewbob

3

J'ai eu un problème similaire dans le passé. Le projet ne fonctionnerait pas en mode débogage.

Il a également été provoqué par une DLL endommagée, mais pas celle d'un 'Hosting'. Ça fait longtemps, donc je ne me souviens pas de la DLL exacte, mais ça avait quelque chose à voir avec la messagerie.

0

Je n'ai pas de réponse précise, mais j'ai une solution qui a fonctionné pour moi.

Fermez le projet/la solution. Via l'explorateur, allez dans le répertoire bin \ debug.Renommez chacun des fichiers présents dans le répertoire. Dans mon cas, j'ai simplement préfixé chaque entrée avec un "xxx". Je l'ai fait de sorte que je puisse revenir en arrière, si nécessaire, car je n'avais pas la confiance nécessaire pour effacer les entrées. En rouvrant le projet/la solution, et en essayant de déboguer à nouveau, semble forcer la régénération de ces fichiers une fois de plus. Pour moi, le programme a repris son travail. Je n'ai aucune idée de la cause spécifique du problème, mais la reconstruction complète des fichiers semble fonctionner, plutôt qu'une simple "construction" qui doit partiellement conserver ce qui existait auparavant.

1

Il existe en fait des questions similaires aux vôtres. La solution de contournement la plus courante consiste à décocher la case "Activer le processus d'hébergement Visual Studio" dans les propriétés du projet.

Je dois parfois basculer entre le débogage sous x64 bit à n'importe quel CPU; recharger le projet et supprimer tous les fichiers * .suo dans le dossier du projet.