Profilatura side-by-side in-process

Articolo
10/09/2014

A partire da .NET Framework 4, è possibile eseguire più versioni di .NET Framework side-by-side nello stesso processo. I profiler devono essere in grado di riconoscere le esecuzioni side-by-side per funzionare in questo ambiente. I profiler progettati per .NET Framework 2,0, .NET Framework 2,0 SP1, .NET Framework 3,0, .NET Framework 3.5 o .NET Framework 3.5 SP1 possono essere utilizzati in .NET Framework 4 se il processo in fase di profilatura non ospita più versioni di .NET Framework. Per ulteriori informazioni sull'utilizzo della profilatura side-by-side in-process, vedere Impostazioni di compatibilità del profiler.

Riconoscimento dell'esecuzione side-by-side

Un profiler è in grado di riconoscere le esecuzioni side-by-side se garantisce che le applicazioni che caricano più runtime non provochino interruzioni inattese nel profiler, ad esempio violazioni di accesso. Il riconoscimento delle esecuzioni side-by-side include i livelli seguenti di supporto:

Profilatura della prima versione. La prima versione di Common Language Runtime (CLR) caricata in un processo viene profilata, a differenza delle versioni successive di CLR. Il profiler deve essere preparato per eseguire più chiamate a CreateInstance sull'oggetto class factory COM, ma non è necessario che supporti l'utilizzo simultaneo e attivo di callback su più istanze dell'oggetto COM. Il profiler accetta semplicemente la prima chiamata a CreateInstance e la chiamata di callback a Initialize della class factory e non esegue le altre operazioni.
Profilatura di una versione. Simile alla profilatura della prima versione, tranne per il fatto che il profiler consente all'utente di scegliere quale versione di CLR sarà profilata, anziché profilare semplicemente la prima versione di CLR caricata.
Profilatura di più versioni. L'utente sceglie una o più versioni (anche tutte) di CLR da profilare. Il profiler utilizza i callback di tali versioni di CLR e richiama le funzioni Info nella versione appropriata. Il profiler deve quindi tenere traccia di quali elementi del runtime (funzioni, domini di applicazione, classi, oggetti e così via) appartengono alle diverse versioni di CLR.

Nota

Un profiler progettato per .NET Framework 4 deve riconoscere le esecuzioni side-by-side.In altre parole, se un profiler implementa l'interfaccia ICorProfilerCallback3, deve implementare uno di questi schemi (profilatura della prima versione, di una versione o di più versioni) per garantire che più runtime non provochino interruzioni inaspettate del profiler.

Requisiti per il supporto della profilatura di più versioni

Per supportare l'opzione di profilatura di più versioni, un profiler deve essere in grado di eseguire le operazioni seguenti:

Associare le chiamate alle funzioni globali con il runtime corretto.
Associare i vari ID (ad esempio ObjectID, FunctionID ClassID, ModuleID AssemblyID, AppDomainID e così via) al runtime corretto e garantire che un ID di un runtime non venga mai passato all'interfaccia ICorProfilerCallback(2,3) di un altro runtime. È tuttavia accettabile passare un puntatore a un'istruzione da qualsiasi runtime o codice nativo nell'implementazione del metodo ICorProfilerInfo::GetFunctionFromIP di qualsiasi runtime.
Gestire le interazioni tra runtime, ad esempio gli stack di chiamate che passano da un runtime a un altro.
Gestire più istanze della classe che implementa ICorProfilerCallback(2,3) attive nello stesso processo.

Il profiler deve fornire in genere un solo oggetto di gestione del profiler responsabile della gestione delle implementazioni delle funzioni globali e dei dati che si estendono in più runtime. Di seguito è riportato un esempio:

Enter/leave/tailcall/FunctionIDMapper Funzione FunctionIDMapper esegue callback da tutti i runtime. L'oggetto di gestione del profiler utilizzerà in genere il parametro clientData da FunctionIDMapper2 o ICorProfilerInfo3::SetFunctionIDMapper2 per determinare il runtime corrispondente.
Percorsi di chiamate nello stack e shadow stack in più runtime.
Registrazione coordinata tra runtime.

Il profiler deve inoltre fornire un oggetto del profiler che implementa le interfacce ICorProfilerCallback. CLR crea un'istanza di questo oggetto del profiler una volta per ogni runtime attivo. L'unico oggetto globale al quale il profiler deve accedere è il gestore del profiler. Il profiler non deve mantenere un riferimento globale alla relativa implementazione di ICorProfilerCallback, perché molte istanze dell'implementazione di ICorProfilerCallback potrebbero essere attive quando il processo contiene più runtime.

Attivazione di profiler

L'attività di attivazione principale è l'associazione dei profiler con le versioni del runtime.

Avvio di profiler

Se si desidera avviare un profiler in tutti i runtime in un determinato processo, impostare le variabili di ambiente COR_PROFILER e COR_ENABLE_PROFILING. (Si tratta della stessa procedura utilizzata in .NET Framework 3.5 e nelle versioni precedenti).

Se si desidera avviare un profiler solo in determinati runtime, impostare le variabili di ambiente COR_PROFILER e COR_ENABLE_PROFILING ed eseguire una delle operazioni seguenti:

Annullare tutte tranne la prima chiamata CreateInstance all'oggetto class factory (profilatura della prima versione).

- oppure -
Consentire tutte le chiamate CreateInstance all'oggetto class factory e nella chiamata Initialize determinare la versione del runtime chiamante. A questo scopo, è necessario eseguire entrambe le azioni seguenti:
- Eseguire il metodo QueryInterface in CLR per l'interfaccia ICorProfilerInfo3. Se questa operazione non riesce, la versione del runtime è 1 o 2.0. L'esecuzione di QueryInterface per l'interfaccia ICorProfilerInfo2 indicherà se la versione del runtime è 2.0 o 1.
- Se ICorProfilerInfo3 è supportato, chiamare il metodo GetRuntimeInformation per ottenere ulteriori informazioni sul runtime in fase di profilatura.
Dopo avere determinato la versione del runtime, il profiler può decidere se profilarlo. In tal caso, continuare come di consueto con l'inizializzazione. In caso contrario, Initialize restituirà un errore. A partire da .NET Framework 4, è possibile che il profiler restituisca un HRESULT CORPROF_E_PROFILER_CANCEL_ACTIVATION per evitare di registrare un errore nel log eventi dell'applicazione di Windows.

Connessione di profiler

Un processo trigger di connessione esegue le operazioni seguenti:

Utilizza il metodo ICLRMetaHost::EnumerateLoadedRuntimes per enumerare i runtime caricati nel processo di destinazione e per trovare il runtime desiderato.
Recupera un'interfaccia ICLRRuntimeInfo dall'interfaccia IEnumUnknown restituita dal metodo ICLRMetaHost::EnumerateLoadedRuntimes.
Ottiene un'interfaccia ICLRProfiling chiamando GetInterface sull'interfaccia ICLRRuntimeInfo con CLSID_CLRProfiling e IID_ICLRProfiling.
Chiama il metodo AttachProfiler tramite l'interfaccia ICLRProfiling.