Je travaille sur une démo sur la détection de collision. (Certains du code pour cela sont détaillés ici .) En mode de débogage, ça marche amende. En mode de sortie, il est plus rapide, mais la détection de collision est vraiment gâchée. Objets à rebondir de rien ou semblent étrangement légèrement effectué par la gravité. Certains objets explosent, comme s'ils sont entrés en collision avec les objets explosifs spéciaux, même si aucun de ces objets n'existe.
Alors ... Que change Visual Studio entre la libération et le mode de débogage qui cause ce problème? (J'utilise VS PRO 2008.)
Mystérieusement, le mode de sortie a travaillé pour beaucoup de développement. Il vient de s'arrêter récemment.
3 Réponses :
Premier, tout #Ifsi (débogage) ou #if (version) Pragmas est entré. Vous pouvez avoir du code dans l'un ou l'autre qui devrait ou ne devrait pas être appelé, alors recherchez ceux-ci.
Au-delà de cela, par défaut, les constructions de version sont définies sur "Optimiser le code", tandis que le débogage n'est pas. Essayez de changer ce paramètre dans votre configuration de version (Projet> Propriétés> Build> "Optimiser le code") et voir si cela résout le problème.
D'accord, il est improbable que l'optimisation .NET tue votre code, mais vous pouvez avoir des conditionnels de pragne dans votre code qui modifient le chemin d'exécution et donc le comportement.
avec le mode de débogage, il existe une définition en place (vous pouvez le confirmer en cochant les "Options de construction" lorsque vous cliquez avec le bouton droit de la souris sur la solution et sélectionnez "Propriétés" qui, si elles sont utilisées, vous pouvez émettre des appels de trace. Dans Mode de sortie, la définition est supprimée et aucune information de débogage n'est utilisée. Si vous devez déboguer ce code de libération, le débogueur ne sera pas en mesure de dire quelle ligne (code d'origine), même si vous avez spécifié l'emplacement de la source. Comme le code est optimisé.
Tant que votre situation, peut-être en supprimant les fichiers de construction intermédiaires dans le répertoire de publication ou en supprimant le fichier .suo trouvé dans le répertoire de solution pourrait aider.
J'espère que cela aide, Meilleures salutations, Tom.
Mes puissances psychiques ne sont pas géniales et il est difficile de dire ce qui se passe sans le déboguer. Mais voici une supposition. Le problème que je discute ici:
Pourquoi ce flottant- Le calcul du point donne des résultats différents sur différentes machines?
s'applique non seulement à "Cross Machine" mais aussi à "Déboguer VS Libération". Il est non seulement possible, mais probablement que la version de sortie de votre programme utilise Maths de précision supérieure que votre version de débogage. Si vous avez des bugs de points flottants, il est tout à fait possible que, juste par Sheer Bad Luck, vous n'allez que dans la version de libération de haute précision et non dans la version de débogage de la plus haute précision.
Pourquoi la différence? Parce que dans la version non optimisée, le compilateur C # génère fréquemment du code pour des valeurs temporaires comme si elles étaient des variables locales; La gigue attribue ensuite réellement des locaux temporaires sur la pile et écrit les valeurs temporaires des registres aux locaux. Ensuite, quand il en a besoin, il les lit dans des registres des temporaires. Ce voyage peut causer la valeur dans le registre de haute précision pour être tronqué à la précision de 64 bits, perdant des morceaux de précision.
Dans la version optimisée, le compilateur C # et la gigue travaillent plus fort pour tout garder dans les registres tout le temps, car évidemment, c'est plus rapide et plus haute précision, bien que plus difficile à déboguer.
bonne chance. Les bugs que représentent seulement le mode de libération sont une douleur totale.