Código puro e verificável (C++/CLI)
Para programação .NET, Visual C++ da suporte à criação dos três tipos distintos de componentes e de aplicativos: misto, puro, e verificável. Todos os três estão disponíveis com a opção do compilador de /clr (compilação do Common Language Runtime) .
Comentários
Para obter mais informações sobre assemblies verificáveis, consulte:
Comparação de recursos mistos, puros e verificáveis (C++/CLI)
Convertendo projetos do modo misto em linguagem intermediária pura
Misto (/clr)
Os assemblies compilados com /clrmistos (), contêm as partes não gerenciado e gerenciados, tornando possível para que usem recursos do .NET, mas ainda contêm código não gerenciado. Isso permite que os aplicativos e os componentes sejam atualizados para usar os recursos do .NET sem exigir que o projeto inteiro seja recriado. Usando o Visual C++ gerenciado para mesclar e o código não gerenciado é chamado dessa maneira C++ Interoperabilidade. Para obter mais informações, consulte Assemblies mistos (nativos e gerenciados) e Nativo e interoperabilidade .NET.
Puro (/clr:pure)
Os assemblies compilados com /clr:puresimples () podem conter tipos nativos e de dados gerenciados, mas somente funções gerenciadas. Como os assemblies mistos, os assemblies permitem puro o interoperabilidade com os DLL nativos com P/Invoke (consulte Usando PInvoke explícito em C++ (atributo DllImport)), mas os recursos de Interoperabilidade C++ não estão disponíveis. Além disso, os assemblies simples não podem exportar as funções acessíveis a partir das funções nativos como pontos de entrada em um puro uso do assembly __clrcall que chama a convenção.
Vantagens de /clr:pure
Melhor desempenho: Como os assemblies simples contêm apenas MSIL, não há nenhuma função nativos e, consequentemente nenhuma transição gerenciado/não gerenciado é necessária. (As chamadas de função feitas com P/Invoke é uma exceção a essa regra.)
Reconhecimento de Appdomain: As funções gerenciadas e os tipos de dados CLR existem dentro de Application Domains, o que afeta sua visibilidade e acessibilidade. Os assemblies são simples domínio (atentos que __declspec (appdomain) é indicado para cada tipo) assim que o acesso a seus tipos e funcionalidade de outros componentes do .NET é mais fácil e mais segura. No, os assemblies puro interoperam com mais facilidade com outros componentes do .NET que os assemblies mistos.
Carga que não seja disco: Os assemblies puros de memória podem ser carregados e passado mesmo. Isso é essencial para usar assemblies do .NET como procedimentos armazenados. Isso difere de assemblies mistos, que devido a uma dependência no windows que carregam mecanismos, deve existir no disco para executar.
Reflexão: Não é possível refletir sobre executáveis mistos, enquanto os assemblies puro fornecem suporte completo de reflexão. Para obter mais informações, consulte Reflexão (C++/CLI).
Controllability de host: Como os assemblies simples contêm apenas MSIL, se comportam de maneira previsível e mais flexìvel dos assemblies mistos quando usados em aplicativos que hospedam CLR e alteram o comportamento padrão.
Restrições de /clr:pure
Essa seção abrange os recursos com suporte não atualmente por /clr:pure.
Os assemblies simples não podem ser chamados por funções não gerenciado. Como consequência os assemblies simples não podem implementar interfaces COM ou retornos de chamada da possibilidade nativo. Os assemblies simples não podem exportar funções pelo __declspec (dllexport) ou dos arquivos de .DEF. Além disso, as funções declaradas com a convenção de __clrcall não podem ser importadas pelo dllimport __declspec (). As funções em um módulo nativo podem ser chamadas de um assembly puro, mas os assemblies simples não podem expor funções acessíveis nativo, portanto expor a funcionalidade em um assembly puro deve ser feita com as funções gerenciadas em um assembly misto. Consulte Como migrar para /clr:pure (C++/CLI) para maiores informações.
As bibliotecas de ATL e de MFC não são suportadas pela compilação pura do modo no Visual C++.
.netmodules Simples não são aceitos como entrada para o vinculador Visual C++. No entanto, arquivos simples de .obj são aceitos pelo vinculador, e os arquivos de .obj contêm um superconjunto de informações contidas em netmodules. Consulte Arquivos .netmodule como entrada de vinculador para maiores informações.
O suporte do COM o compilador (#import) não é suportado, pois esse introduziria instruções não gerenciada no assembly puro.
As opções de ponto flutuante para o alinhamento exceções gerais e a manipulação não são ajustáveis para assemblies puro. No resultado, __declspec (alinhar) não pode ser usado. Isso renderiza alguns arquivos de cabeçalho, como fpieee.h, incompatível com /clr:pure.
A função de GetLastError em PSDK pode resultar em comportamento indefinido durante a criação com /clr:pure.
Verificável (/clr:safe)
A opção do compilador de /clr:safe gerenciar os assemblies verificáveis, como aquelas gravadas no Visual Basic e no C#, conformando-se aos requisitos que permitem que Common Language Runtime (CLR) garanta que o código não violar atuais configurações de segurança. Por exemplo, se as configurações de segurança proíbem um componente de gravação no disco, CLR puder determinar se um componente verificável encontrar esse critério antes de executar um de código. Não há suporte para os assemblies de CRT verificáveis. (Suporte de CRT está disponível para assemblies puro por uma versão pura de MSIL da biblioteca de tempo de execução C).
Os assemblies verificáveis oferecem essas vantagens sobre assemblies simples e mixed:
Segurança emitido.
Algumas situações exigem-na (componentes do SQL, por exemplo).
As versões futuras do windows requerem cada vez mais componentes e aplicativos ser verificáveis.
Uma desvantagem é que os recursos de interoperabilidade C++ não estão disponíveis. Os assemblies verificáveis não podem conter nenhuma função não gerenciado ou tipos de dados nativos, mesmo que elas não sejam referenciadas pelo código gerenciado.
Independentemente do uso de palavras “segura”, criar aplicativos com /clr:safe não significa que não há bugs; significa que apenas CLR pode verificar as configurações de segurança em tempo de execução.
Independentemente do tipo de assembly, as chamadas feitas de assemblies gerenciados a DLL nativos via P/Invoke serão mais, mas podem falhar em tempo de execução dependendo das configurações de segurança.
Dica
Há um cenário codificando que transmitirão o compilador mas que resultará em um assembly não controlável: chamando uma função virtual por meio de um objeto que usa o operador de resolução de escopo. Por exemplo: MyObj -> A::VirtualFunction();.