No processo de criação de perfil lado a lado
Começando com o .NET Framework 4, várias versões do.NET Framework podem ser executados lado a lado no mesmo processo. Geradores de perfis devem estar lado-por-lado-aware para executar nesse ambiente. Geradores de perfis são projetados para trabalhar com o .NET Framework versão 2.0, .NET Framework 2.0 SP1, .NET Framework 3.0, .NET Framework 3.5, ou .NET Framework 3.5 SP1 pode ser usado na .NET Framework versão 4, se o processo que está sendo perfilado não hospeda várias versões do.NET Framework. Para obter mais informações sobre como usar a criação de perfil de lado a lado no processo, consulte Configurações de compatibilidade do Profiler.
Reconhecimento de lado a lado
Um gerador de perfil é lado-por-lado-aware se ele garante que os aplicativos que carregar vários tempos de execução não causam o profiler encontrar quebra inesperada, como, por exemplo, violações de acesso. Reconhecimento de lado a lado inclui os seguintes níveis de suporte:
Perfil primeiro. A primeira versão de runtime (CLR) idioma comum que é carregada em um processo é perfilada, mas não as versões subseqüentes do CLR. O criador de perfil deve ser preparado para vários CreateInstance chamadas sejam feitas em seu objeto de fábrica de classe COM, mas não tem que oferecer suporte ao uso simultâneo, ativo de retornos de chamada de várias instâncias do seu objeto COM. O profiler simplesmente aceita a fábrica de primeira classe CreateInstance de chamada e inicializar chamada de retorno de chamada e o restante de falhar.
Criar o perfil de um. Semelhante ao perfil primeiro, exceto que o profiler permite que o usuário escolha qual versão do CLR será perfilado, em vez de simplesmente a primeira versão do CLR é carregada na criação de perfil.
Perfil muitos. O usuário escolhe um ou mais (possivelmente todas) as versões do CLR para perfil. O profiler consome retornos de chamada dessas versões do CLR e chamadas Info funções de volta para a versão apropriada. Isso requer que o profiler controlar quais itens de tempo de execução (funções, domínios de aplicativo, classes, objetos e assim por diante) pertencem ao CLR.
Observação
Um gerador de perfil destina-se a .NET Framework 4 deve estar lado-por-lado-aware.Ou seja, se um gerador de perfil implementa o ICorProfilerCallback3 interface, ele deve implementar um dos seguintes esquemas (perfil primeiro, um ou muitos de perfil) para garantir que vários tempos de execução não causam o profiler encontrar quebra inesperada.
Requisitos para suportam a muitos de perfil
Para oferecer suporte o perfil opção muitos, um gerador de perfil deve ser capaz de fazer o seguinte:
Associe chamadas a funções globais com o tempo de execução correto.
Associar as várias IDs (por exemplo, ObjectID FunctionID, ClassID, ModuleID, AssemblyID, AppDomainID e assim por diante) o tempo de execução correto e certifique-se de que uma identificação de um tempo de execução nunca é transmitida do runtime ICorProfilerCallback(2,3) interface. No entanto, é aceitável para passar o ponteiro de qualquer instrução de qualquer tempo de execução ou o código nativo para a implementação do runtime da ICorProfilerInfo::GetFunctionFromIP método.
Lidar com as interações entre os tempos de execução, como, por exemplo, pilhas de chamada que passar do tempo de execução de um para outro.
Lidar com várias instâncias de sua classe que implementa ICorProfilerCallback(2,3) sendo ativa no mesmo processo.
Geralmente, o profiler deve fornecer um objeto do Gerenciador de único profiler é responsável pela manipulação de implementações de função global e os dados relativos a vários tempos de execução. Por exemplo:
Entrar/sair/tailcall/FunctionIDMapperFunção de FunctionIDMapper retornos de chamada de todos os tempos de execução. O objeto do Gerenciador de profiler geralmente usarão o clientData parâmetro do FunctionIDMapper2 ou ICorProfilerInfo3::SetFunctionIDMapper2 para determinar o tempo de execução correspondente.
Movimentações de pilha e pilhas de sombra entre tempos de execução.
Log coordenado entre os tempos de execução.
O profiler também deve fornecer um objeto do profiler que implementa o ICorProfilerCallback interfaces. O CLR instancia a este objeto profiler, uma vez para cada ativo em tempo de execução. O objeto global somente que o profiler deve acessar é o Gerenciador de profiler. O profiler não deve manter uma referência global ao seu ICorProfilerCallback implementação, porque muitas instâncias da ICorProfilerCallback implementação pode ser ativa quando o processo contém vários tempos de execução.
Ativando os geradores de perfis
A tarefa principal de ativação é a associação de criadores de perfis com versões do runtime.
Iniciando os geradores de perfis
Se você quiser iniciar um gerador de perfil de todos os tempos de execução em um determinado processo, defina as variáveis de ambiente COR_PROFILER e COR_ENABLE_PROFILING. (Esse é o mesmo procedimento como o.NET Framework 3.5 e versões anteriores.)
Se você quiser iniciar um gerador de perfil somente em determinados tempos de execução, defina as variáveis de ambiente COR_PROFILER e COR_ENABLE_PROFILING e faça o seguinte:
A falha todas, exceto a primeira CreateInstance de chamada para o objeto de classe de fábrica (primeiro perfil).
- ou -
Permitir que todos os CreateInstance chama o objeto de classe de fábrica e no Initialize chamar, determine a versão do runtime de chamada. Para fazer isso, você deve fazer as seguintes ações:
Execute o QueryInterface método no CLR para a ICorProfilerInfo3 interface. Se isso falhar, a versão de tempo de execução é 1 ou 2.0. Executando QueryInterface para o ICorProfilerInfo2 interface revelará se o tempo de execução é um runtime versão 2.0 ou um tempo de execução da versão 1.
Se ICorProfilerInfo3 é suportado, chamar o GetRuntimeInformation método para obter mais informações sobre o tempo de execução está sendo perfilada.
Quando a versão do runtime tiver sido determinada, o profiler pode optar por criar o perfil desse tempo de execução. Nesse caso, continue com a inicialização normalmente. Se não for, retornará um erro de Initialize. Começando com o .NET Framework 4, o profiler pode retornar um CORPROF_E_PROFILER_CANCEL_ACTIVATION HRESULT para evitar causando um erro devem ser registrados para o log de eventos do aplicativo Windows
Anexando geradores de perfis
Um processo de disparador anexar faz o seguinte:
Usa a ICLRMetaHost::EnumerateLoadedRuntimes método para enumerar os tempos de execução são carregados no processo de destino e para encontrar o tempo de execução de seu interesse.
Recupera um ICLRRuntimeInfo interface da IEnumUnknown interface que é retornado de ICLRMetaHost::EnumerateLoadedRuntimes método.
Obtém um ICLRProfiling interface chamando GetInterface sobre o ICLRRuntimeInfo interface com CLSID_CLRProfiling e IID_ICLRProfiling.
Chamadas de AttachProfiler método por meio de ICLRProfiling interface.
Para obter mais informações sobre a anexação de geradores de perfis, consulte Profiler anexar e desanexar.
Consulte também
Conceitos
Visão geral de criação de perfil