Como: Migrar para o /clr: puro
Este tópico discute os problemas que surgirão ao migrar para o uso de MSIL Puro /clr:pure (consulte /CLR (common Language Runtime Compilation) para obter mais informações). Este tópico pressupõe que o código que está sendo migrado atualmente é cumpriu como misto assembly usando a /clr opção, como o caminho de migração de código não gerenciado para o MSIL puro não é uma direct. Para código não gerenciado, consulte Como: Migrar para /clr antes de tentar migrar para o MSIL puro.
Alterações básicas
MSIL puro é composto de instruções MSIL, portanto, o código que contém funções que não podem ser expresso em MSIL impedirá a compilação. Isso inclui funções definidas como usando convenções de chamada seja __clrcall. (Funções de __clrcall não podem ser invocadas em um componente MSIL puro, mas não definidas.)
Para garantir que nenhum erro de tempo de execução, você deve ativar o aviso de C4412. Habilitar C4412 adicionando #pragma warning (default : 4412) para cada compiland que você compilar com /clr:pure e passa os tipos de C++ e para IJW (/clr) ou código nativo. See C4412 de aviso (nível 2) do compilador for more information.
Considerações sobre arquitetura
Algumas das limitações de assemblies MSIL puros listados na Código puro e verificável têm implicações de alto nível para o aplicativo design e migração de estratégia. Notavelmente, ao contrário de assemblies mistos, assemblies MSIL puros não desfrutam de compatibilidade total com os módulos de não gerenciados.
Assemblies MSIL puros podem chamar funções não gerenciadas, mas não podem ser chamados por funções não gerenciadas. Como resultado, o MSIL puro é um melhor candidato para o código do cliente que usa funções não gerenciadas que o código do servidor é usado por funções não gerenciadas. Se a funcionalidade contida em um assembly MSIL puro é para ser usado por funções não gerenciadas, um conjunto misto deve ser usado como uma camada de interface.
Aplicativos que usam ATL ou MFC não são bons candidatos à migração para o MSIL puro, como essas bibliotecas não são suportadas nesta versão. Da mesma forma, o Windows SDK contém os arquivos de cabeçalho que não compilar em /clr:pure.
Enquanto os assemblies MSIL puros podem chamar funções não gerenciadas, essa capacidade é limitada a funções simples de estilo C. O uso de APIs não gerenciadas de mais complexas é provável que requerem a funcionalidade não gerenciada para ser exposto na forma de uma interface COM ou um assembly misto que pode atuar como uma interface entre o MSIL puro e os componentes não gerenciados. O uso de uma camada de assembly misto é a única maneira de usar as funções não gerenciadas, utilizar as funções de retorno de chamada, por exemplo, como um assembly puro é capaz de fornecer uma função callable nativa para ser usado como um retorno de chamada.
Domínios de aplicativo e convenções de chamada
Embora seja possível para o MSIL Puro assemblies usam a funcionalidade não gerenciada, funções e dados estáticos são tratados de maneira diferente. Em assemblies puros, as funções são implementadas com o __clrcall chamada convenção e dados estáticos é armazenado por aplicativos de domínio. Isso é diferente do padrão para assemblies não gerenciados e mistos que usam o __cdecl convenção para funções de chamada e armazenar dados estáticos em uma base por processo.
Dentro do contexto de MSIL puro (e verificável código compilado com /CLR: safe) esses padrões são transparentes, como __clrcall é o padrão de convenção do CLR de chamada e domínios de aplicativo são o escopo de nativo para dados estáticos e globais.Aplicativos de NET. No entanto, quando uma interface com componentes não gerenciados ou mistos, o tratamento de diferente das funções e dos dados globais pode causar problemas.
Por exemplo, se um componente MSIL puro é chamar funções em uma DLL não gerenciada ou mista, um arquivo de cabeçalho para a DLL ser usado para compilar o assembly puro. No entanto, a menos que a convenção de chamada para cada função no cabeçalho é indicada explicitamente, eles serão todos considerados __clrcall. Isso mais tarde causará falhas de tempo de execução, como essas funções provavelmente implementado com o __cdecl convenção. As funções no arquivo de cabeçalho não gerenciado podem ser explicitamente marcadas como __cdecl, ou todo o código de origem da DLL deve ser recompilado em /clr:pure.
Da mesma forma, os ponteiros de função são considerados para apontar para __clrcall funções em /clr:pure compilação. Eles também devem ser anotados explicitamente com a convenção de chamada correta.
For more information, see Domínios de aplicativo e o Visual C++.
Linking Limitations
O vinculador do Visual C++ não tentará vincular arquivos OBJ puros e mistos, pois as convenções de chamada e de escopo de armazenamento são diferentes.