Como: migrar para /clr: puro (C + + / CLI)
Este tópico aborda 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 o /clr opção, como o caminho de migração de código não gerenciado para MSIL puro não é direta.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 da MSIL para que 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 compilar com /clr:pure e passa os tipos de C++ para e de IJW (/clr) ou código nativo.Consulte C4412 de aviso (nível 2) do compilador para maiores informações.
Considerações de arquitetura
Algumas das limitações de assemblies MSIL puros listados na Código puro e verificável (C + + / CLI) têm implicações de alto nível para a estratégia de projeto e migração de aplicativos.Notavelmente, ao contrário de assemblies mistos, assemblies MSIL puros não desfrutam de compatibilidade total com módulos 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, MSIL puro é um candidato melhor para código do cliente que usa funções não gerenciadas que código de servidor que é 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 assembly 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, pois essas bibliotecas não são suportadas nesta versão.Da mesma forma, o Windows SDK contém arquivos de cabeçalho não compilar em /clr:pure.
Enquanto os assemblies MSIL puros podem chamar funções não gerenciadas, essa capacidade é limitada a funções de estilo c simples.O uso de APIs não gerenciadas mais complexos é provável que 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 componentes não gerenciados.Usando uma camada de assembly misto é a única maneira de usar funções não gerenciadas que levam a funções de retorno de chamada, por exemplo, como um assembly puro é capaz de fornecer uma função callable nativa para uso como um retorno de chamada.
Domínios de aplicativo e convenções de chamada
Embora seja possível para MSIL puro assemblies usam funcionalidade não gerenciada, funções e dados estáticos são tratados de maneira diferente.Em assemblies puros, funções são implementadas com o __clrcall dados estáticos e convenção de chamada é armazenado por aplicativo domínio.Isso é diferente do padrão para assemblies não gerenciados e mistos que usam o cdecl convenção de chamada para funções e armazenar dados estáticos em uma base por processo.
Dentro do contexto do MSIL puro (e código verificável compilado com /CLR: safe) esses padrões são transparentes, como __clrcall é a convenção de chamada padrão do CLR e domínios de aplicativo são o escopo de nativo para dados estáticos e globais.NET applications.No entanto, quando uma interface com componentes não gerenciados ou mistas, o tratamento de diferente funções e dados globais pode causar problemas.
Por exemplo, se um componente MSIL puro for 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 são provavelmente implementado com o cdecl convenção.As funções no arquivo de cabeçalho não gerenciados podem ser marcadas explicitamente como cdecl, ou o código de origem inteiro DLL deve ser recompilado em /clr:pure.
Da mesma forma, os ponteiros de função são considerados para apontar para __clrcall funciona em /clr:pure compilação.Eles também devem ser anotados explicitamente com a convenção de chamada correta.
Para mais informações, consulte Domínios de aplicativos e Visual C++.
Limitações de vinculação
O vinculador Visual C++ não tentará vincular arquivos OBJ mistos e puros, como as convenções de escopo e chamada de armazenamento são diferentes.