Profilage côte à côte in-process
À compter du .NET Framework 4, plusieurs versions du .NET Framework peuvent s'exécuter côte à côte dans un même processus. Les profileurs doivent être activés pour la fonctionnalité côte à côte pour pouvoir être utilisés dans cet environnement. Les profileurs conçus pour utiliser le .NET Framework version 2.0, .NET Framework 2.0 SP1, .NET Framework 3.0, .NET Framework 3.5 ou .NET Framework 3.5 SP1 peuvent être utilisés dans le .NET Framework version 4, si le processus en cours de profilage n'héberge pas plusieurs versions du .NET Framework. Pour plus d'informations sur l'utilisation du profilage côte à côte in-process, consultez Paramètres de compatibilité des profileurs.
Activation de la fonctionnalité côte à côte
Un profileur est activé pour la fonctionnalité côte à côte s'il garantit que les applications qui chargent plusieurs runtimes ne génèrent pas d'erreurs inattendues, telles que des violations d'accès. L'activation de la fonctionnalité côte à côte inclut les niveaux de prise en charge suivants :
Profiler premier. La première version du Common Language Runtime (CLR) chargée dans un processus est profilée, mais les versions du CLR suivantes ne le sont pas. Le profileur doit anticiper l'exécution de plusieurs appels CreateInstance sur son objet de fabrique de classes COM, mais n'a pas besoin de prendre en charge l'utilisation simultanée et active de rappels sur plusieurs instances de son objet COM. Le profileur accepte simplement le premier appel CreateInstance de fabrique de classes et le rappel Initialise et échoue pour le reste.
Profiler un. Similaire à « profiler premier », sauf que le profileur permet à l'utilisateur de choisir quelle version du CLR sera profilée, au lieu de simplement profiler la première version du CLR chargée.
Profiler plusieurs. L'utilisateur choisit une ou plusieurs versions du CLR (toutes s'il le souhaite) à profiler. Le profileur utilise les rappels de ces versions du CLR et rappelle les fonctions Info dans la version appropriée. Cela exige du profileur qu'il effectue le suivi des éléments d'exécution (fonctions, domaines d'application, classes, objets, etc.) par rapport à leur CLR.
.gif "Remarque") Remarque |
|---|
Un profileur conçu pour le .NET Framework 4 doit être activé pour la fonctionnalité côte à côte.Autrement dit, si un profileur implémente l'interface ICorProfilerCallback3, il doit implémenter l'un de ces schémas (profiler le premier, profiler un ou profiler plusieurs) pour garantir que plusieurs runtimes ne génèrent pas d'erreurs inattendues. |
Spécifications pour la prise en charge de « profiler plusieurs »
De prendre en charge l'option « profiler plusieurs », un profileur doit être en mesure d'effectuer les opérations suivantes :
Associer des appels aux fonctions globales avec le runtime approprié.
Associer les différents ID (tels que, ObjectID, FunctionID, ClassID, ModuleID, AssemblyID, AppDomainID, etc.) avec le runtime approprié, et garantir qu'un ID d'un runtime n'est jamais passé à l'interface ICorProfilerCallback(2,3) d'un autre runtime. Il est toutefois possible de passer un pointeur d'instruction d'un runtime ou d'un code natif dans l'implémentation du runtime de la méthode ICorProfilerInfo::GetFunctionFromIP.
Gérer les interactions entre runtimes, telles que les piles d'appels qui passent d'un runtime à un autre.
Gérer plusieurs instances de sa classe qui implémente ICorProfilerCallback(2,3) actif dans le même processus.
Le profileur doit généralement fournir un objet de gestionnaire du profileur unique qui est chargé de la gestion des implémentations de fonctions globales et des données qui couvrent plusieurs runtimes. Par exemple :
Rappels enter/leave/tailcall/FunctionIDMapperFunctionIDMapper (fonction) à partir de tous les runtimes. L'objet de gestionnaire du profileur utilise généralement le paramètre clientData de FunctionIDMapper2 ou ICorProfilerInfo3::SetFunctionIDMapper2 pour déterminer le runtime correspondant.
Parcours de pile et piles cachées entre runtimes.
Enregistrement coordonné entre runtimes.
Le profileur doit également fournir un objet de profileur qui implémente les interfaces ICorProfilerCallback. Le CLR instancie cet objet une fois pour chaque runtime actif. Le seul objet global auquel le profileur doit accéder est le gestionnaire de profileur. Le profileur ne doit pas conserver de référence globale à son implémentation ICorProfilerCallback, car de nombreuses instances de l'implémentation ICorProfilerCallback peuvent être actives lorsque le processus contient plusieurs runtimes.
Activation de profileurs
La principale tâche d'activation est l'association des profileurs avec les versions du runtime.
Lancement de profileurs
Si vous souhaitez lancer un profileur dans tous les runtimes d'un processus donné, définissez les variables d'environnement COR_PROFILER et COR_ENABLE_PROFILING. (La procédure est la même que dans le .NET Framework 3.5 et les versions précédentes.)
Si vous voulez lancer un profileur uniquement dans certains runtimes, définissez les variables d'environnement COR_PROFILER et COR_ENABLE_PROFILING, puis effectuez l'une des opérations suivantes :
Échouez tout, à l'exception du premier appel CreateInstance à l'objet de fabrique de classes (profiler premier).
- ou -
Autorisez tous les appels CreateInstance à l'objet de fabrique de classes, et dans l'appel Initialize, déterminez la version du runtime appelant. Pour ce faire, vous devez effectuer les deux actions suivantes :
Exécutez la méthode QueryInterface sur le CLR pour l'interface ICorProfilerInfo3. En cas d'échec, la version du runtime est 1 ou 2.0. L'exécution de QueryInterface pour l'interface ICorProfilerInfo2 indiquera si le runtime est un runtime de version 2.0 ou de version 1.
Si ICorProfilerInfo3 est pris en charge, appelez la méthode GetRuntimeInformation pour obtenir plus d'informations à propos du runtime en cours de profilage.
Lorsque la version du runtime a été déterminée, le profileur peut décider s'il faut profiler ce runtime. Si oui, continuez l'initialisation comme d'habitude. Si non, retournez une erreur à partir de Initialize. À compter du .NET Framework 4, le profileur peut retourner un CORPROF_E_PROFILER_CANCEL_ACTIVATIONHRESULT pour éviter de provoquer l'enregistrement d'une erreur dans le journal des événements des applications Windows.
Attachement des profileurs
Un processus de déclenchement d'attachement effectue les opérations suivantes :
Utilise la méthode ICLRMetaHost::EnumerateLoadedRuntimes pour énumérer les runtimes chargés dans le processus cible, et trouver le runtime recherché.
Extrait une interface ICLRRuntimeInfo de l'interface IEnumUnknown retournée à partir de la méthode ICLRMetaHost::EnumerateLoadedRuntimes.
Obtient une interface ICLRProfiling en appelant GetInterface sur l'interface ICLRRuntimeInfo avec CLSID_CLRProfiling et IID_ICLRProfiling.
Appelle la méthode AttachProfiler via l'interface ICLRProfiling.
Pour plus d'informations sur l'attachement de profileurs, consultez Attachement au profileur et détachement du profileur.