Problèmes courants lors de la création d’une version release
Pendant le développement, vous allez généralement générer et tester avec une build de débogage de votre projet. Si vous générez ensuite votre application pour une build de mise en production, vous risquez d’obtenir une violation d’accès.
La liste ci-dessous présente les principales différences entre une build de débogage et une build de mise en production (nondebug). Il existe d’autres différences, mais voici les principales différences qui entraîneraient l’échec d’une application dans une build de mise en production lorsqu’elle fonctionne dans une build de débogage.
Consultez l’option du compilateur /GZ (Catch Release-Build Errors in Debug Build) pour plus d’informations sur la façon d’intercepter les erreurs de build de mise en production dans les builds de débogage.
Disposition du tas
La disposition du tas est la cause d’environ 90 % des problèmes apparents lorsqu’une application fonctionne dans le débogage, mais pas la mise en production.
Lorsque vous générez votre projet pour le débogage, vous utilisez l’allocateur de mémoire de débogage. Cela signifie que toutes les allocations de mémoire ont des octets de garde placés autour d’eux. Ces octets de protection détectent un remplacement de mémoire. Étant donné que la disposition du tas est différente entre les versions de mise en production et de débogage, un remplacement de mémoire peut ne pas créer de problèmes dans une build de débogage, mais peut avoir des effets catastrophiques dans une build de mise en production.
Pour plus d’informations, consultez Rechercher le remplacement de la mémoire et utiliser la build de débogage pour rechercher le remplacement de mémoire.
Compilation
La plupart des macros MFC et une grande partie des modifications apportées à l’implémentation MFC lorsque vous générez pour la mise en production. En particulier, la macro ASSERT n’est évaluée à rien dans une build de mise en production. Par conséquent, aucun du code trouvé dans ASSERTs n’est exécuté. Pour plus d’informations, consultez Examiner les instructions ASSERT.
Certaines fonctions sont inline pour augmenter la vitesse dans la build de mise en production. Les optimisations sont généralement activées dans une build de mise en production. Un allocateur de mémoire différent est également utilisé.
Prise en charge du pointeur
Le manque d’informations de débogage supprime le remplissage de votre application. Dans une build de mise en production, les pointeurs errants ont une plus grande chance de pointer vers une mémoire non initialisée au lieu de pointer vers des informations de débogage.
Optimisations
Selon la nature de certains segments de code, l’optimisation du compilateur peut générer du code inattendu. Il s’agit de la cause la moins probable des problèmes de build de mise en production, mais cela se produit à l’occasion. Pour une solution, consultez Optimisation de votre code.
Voir aussi
Versions Release
Résolution de problèmes liés à la version Release