Como: Migrar para o/CLR: puro
Este tópico aborda problemas podem surgir durante a migração para o MSIL puro usando /clr:pure (consulte a o CLR (ComComummon Idioma Tempo de execução ComComumpilation) Para obter mais informações). Este tópico pressupõe que o código que está sendo migrado no momento é observou sistema autônomo misto assembly usando o /clr opção, sistema autônomo o caminho de migração de código não gerenciado para MSIL puro não é direta. Para obter um código não gerenciado, consulte Como: Migrar para o 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 sistema autônomo usando convenções de chamada seja __clrcall. (Funções __clrcall não podem ser chamadas em um componente MSIL puro, mas não definidas.)
Para garantir que nenhum erro de tempo de execução, você deve ativar warnnig C4412.Ativar C4412 adicionando #pragma warning (default : 4412) para cada compiland compilar com /clr:pure e tipos de C++ para e de IJW (que passa**/clr)** ou código nativo. Consulte Compilador C4412 de aviso (nível 2) para obter mais informações.
Considerações sobre arquitetura
Algumas das limitações dos assemblies MSIL puros listados em Código puro e verificável têm implicações de alto nível para a estratégia de projeto e migração do aplicativo. Em especial, ao contrário dos assemblies mistos, assemblies MSIL puros não desfrutam de compatibilidade total com módulos não gerenciados.
Assemblies MSIL puros podem telefonar não gerenciados funções, mas não pode ser telefonar ed por funções não gerenciadas.sistema autônomo resultado, MSIL puro é um melhor candidato para código do cliente que usa funções não gerenciadas que para código de servidor que é usado por funções não gerenciadas.Se funcionalidade contida em um assembly MSIL puro deve ser usado por funções não gerenciadas, um conjunto misto deve ser usado sistema autônomo uma camada de interface.
Aplicativos que usam ATL ou MFC não são mercadoria candidatos à migração para o MSIL puro, pois essas bibliotecas não são aceitos nesta versão.Da mesma forma, a Windows SDK contém arquivos de cabeçalho não compilar em /clr:pure.
Enquanto os assemblies MSIL puros podem telefonar funções não gerenciadas, essa capacidade é limitada a funções simples de estilo C.O uso de APIs não gerenciadas mais complexas é provável que exigem a funcionalidade não gerenciada para ser exposto em forma de uma interface COM ou um conjunto misto pode atuar sistema autônomo uma interface entre o MSIL puro e sistema autônomo componentes não gerenciados.Usando uma camada de assembly misto é a única maneira de usar funções não gerenciadas que utilizar sistema autônomo funções de retorno de chamada, por exemplo, sistema autônomo um assembly puro não consegue fornecer uma função nativa que pode ser chamada para uso sistema autônomo um retorno de chamada.
aplicativo Domínios e convenções de chamada
Embora seja possível para MSIL puro assemblies use funcionalidade não gerenciada, funções e dados estático são tratados de maneira diferente.Nos assemblies puros, funções são implementadas com o __clrcall chamar convenção e dados estático é armazenado por aplicativos de 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 armazenamento de dados estático em uma base por processo.
Dentro do contexto da MSIL puro (e verificável código compilado com/CLR: safe) esses padrões são transparente, sistema autônomo __clrcall é a convenção de chamada padrão do CLR e domínios de aplicativo são o escopo nativo para dados estático e global nos aplicativos .NET. No entanto, quando uma interface com componentes não gerenciados ou mistos, o tratamento das funções e dos dados global diferente 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 é explicitamente indicada, eles serão considerado todos como para ser __clrcall. Isso mais tarde causará falhas de tempo de execução, sistema autônomo essas funções provavelmente são implementadas com o __cdecl convenção. sistema autônomo funções no arquivo de cabeçalho não gerenciados podem ser marcadas explicitamente sistema autônomo __cdecl, ou todo o código de fonte 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. Esses muito devem ser explicitamente anotados com a convenção de chamada correta.
Para obter mais informações, consulte aplicativo Domínios e Visual C++.
Limitações de Vinculação
The Microsoft Visual C++ 2005 Vinculador não tentará vincular arquivos OBJ mistos e puros, pois sistema autônomo convenções de chamada e de escopo de armazenamento são diferentes.