Partager via

Modifications de l'API de débogage dans .NET Framework 2.0

  • Article

Cette rubrique explique les modifications apportées à .NET Framework version 2.0 que vous devez prendre en considération lorsque vous utilisez l'API de débogage du Common Language Runtime (CLR).

Modifications de l'API

  • CorDebug n'est plus une coclasse. Au lieu de la co-créer, utilisez la fonction statique globale CreateDebuggingInterfaceFromVersion dans l'API d'hébergement. La version de débogueur doit être l'une des constantes de l'énumération CorDebugInterfaceVersion dans CorDebug.idl. (Utilisez la constante CorDebugVersion_2_0 si votre débogueur prend en charge le .NET Framework 2.0.) Utilisez la fonction statique globale GetVersionFromProcess dans l'API d'hébergement pour obtenir la version du programme débogué pour un processus en cours d'exécution. Vous pouvez également utiliser la fonction statique globale GetRequestedRuntimeVersion dans l'API d'hébergement pour avoir une meilleure idée de la version qui sera chargée pour un fichier .exe donné sur le disque, ou demander à l'utilisateur de choisir une version du runtime. (Vous pouvez utiliser la fonction statique globale de GetRequestedRuntimeInfo dans l'API d'hébergement pour déterminer si la chaîne fournie par l'utilisateur est une version valide.) Toutes ces fonctions sont définies dans MSCorEE.idl.

  • Un débogueur doit implémenter l'interface ICorDebugManagedCallback2 pour être reconnu en tant que débogueur compatible .NET Framework 2.0.

  • Les valeurs de retour ICorDebugEnum sont conformes à COM dans .NET Framework 2.0.

  • Les nouveaux objets ICorDebugInternalFrame peuvent apparaître dans les traces de la pile où le runtime a inséré un frame spécial pour accomplir une tâche donnée. Ces frames ne répondront pas à une requête QueryInterface pour l'interface ICorDebugNativeFrame ou ICorDebugILFrame.

  • Le délai d'expiration pour la méthode ICorDebugController::Stop est ignoré.

  • Vous pouvez utiliser la méthode ICorDebugModule::EnableJITDebugging uniquement lorsque le module est chargé la première fois. Si cette méthode est utilisée dans un rappel ModuleLoad qui est publié dans le cadre d'une opération attach, elle échouera. (Cette restriction garantit que le module possède un code cohérent pour toutes ses fonctions.)

  • Le code natif pour une fonction donnée dans le .NET Framework ne peut pas être dans un bloc de mémoire contigu unique. En conséquence, les débogueurs ne doivent plus utiliser les méthodes GetAddress, GetSizeet GetCode de l'interface ICorDebugCode. À la place, ils doivent utiliser ICorDebugCode2::GetCodeChunks et ICorDebugProcess::ReadMemory.

  • Les débogueurs en mode mixte doivent définir des points d'arrêt non managés en utilisant la nouvelle méthode ICorDebugProcess2::SetUnmanagedBreakpoint.

  • L'événement de débogage de sortie de thread natif est hors plage dans .NET Framework 2.0.

  • Les objets dans l'API de débogage sont invalidés plus agressivement. Si une opération qui a réussi dans .NET Framework 1.0 ou 1.1 retourne CORDBG_E_OBJECT_NEUTERED dans .NET Framework 2.0, l'interface sur laquelle l'opération a été exécutée a dépassé sa durée de vie et doit être obtenue de nouveau. Les valeurs qui ont été obtenues à partir des opérations dans .NET Framework 1.0 et 1.1 ne sont peut-être pas correctes.

Génériques

L'introduction de génériques dans .NET Framework 2.0 remet en cause de nombreuses suppositions qu'un débogueur a pu faire dans les versions antérieures. Les débogueurs doivent s'orienter vers l'utilisation des formulaires suivants prenant en charge les génériques des fonctions ICorDebug :

Voir aussi

Concepts

Vue d'ensemble du débogage CLR

Autres ressources

Débogage (Référence des API non managées)