Código puro e verificável
Para.NET Programming, Visual C++ oferece suporte a criação de três tipos distintos de componentes e aplicativos: misto, puro e verificável. Todos os três estão disponíveis através do /CLR (common Language Runtime Compilation) opção de compilador.
Comentários
Para obter mais informações sobre assemblies verificáveis, consulte:
Misto (/ clr)
Misto de assemblies (compilado com /clr), contêm partes gerenciados e não, possibilitando que eles usem.NET de recursos, mas ainda conter código não gerenciado. Isso permite que os aplicativos e componentes ser atualizado usar.NET recursos sem exigir que todo o projeto ser reescrito. Usando o Visual C++ para misturar código gerenciado e, dessa maneira é chamada de interoperabilidade de C++. For more information, see Mistos de Assemblies (nativos e gerenciados) and Nativo e.NET interoperabilidade.
Puro (/ clr: puro)
Assemblies puros (compilado com /clr:pure) pode conter os dois tipos de dados nativos e gerenciados, mas só gerenciados funções. Como assemblies mistos, assemblies puros permitem interoperabilidade com DLLs nativas por meio de P/Invoke (consulte Usando PInvoke explícita em C++ (atributo DllImport)), mas os recursos de interoperabilidade de C++ não estão disponíveis. Além disso, os assemblies puros não é possível exportar funções que podem ser chamadas de funções nativas como pontos de entrada em um assembly puro usam o __clrcall chamando convenção.
Vantagens do /clr: puro
Melhor desempenho: Como assemblies puros contêm apenas MSIL, não há nenhum funções nativas e, portanto, sem transições gerenciados/não são necessárias. (Chamadas de função feitas por meio de P/Invoke são uma exceção a essa regra).
Reconhecimento do AppDomain: Funções gerenciadas e tipos de dados CLR existirem dentro de Application Domains, que afeta sua visibilidade e acessibilidade. Assemblies puros estão cientes do domínio (__declspec (appdomain) está implícito para cada tipo) então acessar seus tipos e a funcionalidade dos outros.Componentes de rede é mais fácil e mais seguro. Como resultado, assemblies puros mais facilmente interoperam com outros.NET componentes que os assemblies de mistos.
Carregamento do disco não: Puros assemblies podem ser carregados na memória e até mesmo em fluxo. Isso é essencial para o uso.NET assemblies como procedimentos armazenados. Isso difere do assemblies mistos, que, devido a uma dependência no Windows, carregando os mecanismos, deve existir no disco para executar.
Reflexão: Não é possível refletir sobre executáveis misto, enquanto os assemblies puros fornecem suporte a reflexão completo. For more information, see Reflexão em C++.
Controllability de host: Como assemblies puros contêm apenas MSIL, elas se comportam mais previsível e flexível que misto assemblies quando usados em aplicativos que hospedam o CLR e modificar seu comportamento padrão.
Limitações do /clr: puro
Esta seção aborda os recursos não suportados atualmente pelo /clr:pure.
Assemblies puros não podem ser chamados por funções não gerenciadas. Portanto, assemblies puros não podem implementar interfaces COM ou expor native callbacks. Assemblies puros não é possível exportar funções via __declspec(dllexport) ou.Arquivos de definição. Além disso, funções declaradas com a convenção de __clrcall não podem ser importadas por meio de __declspec(dllimport). Funções em um módulo nativo podem ser chamadas a partir de um assembly puro, mas os assemblies puros não podem expor funções podem ser chamadas nativos, para que expor a funcionalidade de um assembly puro deve ser feito por meio de funções gerenciadas em um conjunto misto. See Como: Migrar para o /clr: puro for more information.
Bibliotecas ATL e MFC não são suportadas por compilação em modo puro no Visual C++.
Puro. netmodules não são aceitos como entrada para o vinculador do Visual C++. Entretanto, os arquivos obj puro são aceitos pelo vinculador e arquivos. obj contêm um superconjunto de informações contidas no netmodules. See arquivos. netmodule como entrada de vinculador for more information.
Suporte do compilador COM (# Import) não é suportada, como isso introduziria instruções não gerenciadas no assembly puro.
Opções de alinhamento e a manipulação de exceção não forem ajustáveis para assemblies puros do ponto de flutuante. Como resultado, o __declspec(align) não pode ser usado. Isso apresenta alguns arquivos de cabeçalho, como, por exemplo, fpieee.h, incompatível com o /clr: puro.
A função GetLastError o PSDK pode dar um comportamento indefinido durante a compilação com /clr:pure.
Verificável (/ /CLR: safe)
O /clr:safe opção de compilador gera assemblies verificáveis, como aqueles escritos em Visual Basic e C# em conformidade com os requisitos que permitem que o common language runtime (CLR) para garantir que o código não violar as configurações de segurança atual. Por exemplo, se as configurações de segurança proíbem a um componente de gravação em disco, o CLR pode determinar se um componente verificável atende a esse critério antes de executar qualquer código de. Não há nenhum suporte de CRT para assemblies verificáveis. (O suporte do CRT é disponível para assemblies puros através de uma versão de MSIL Puro da biblioteca C Runtime).
Assemblies verificáveis oferecem essas vantagens sobre assemblies puros e mistos:
Maior segurança.
Algumas situações requerem (componentes SQL, por exemplo).
Cada vez mais exigirá futuras versões do Windows, componentes e aplicativos para que seja verificável.
Uma desvantagem é que os recursos de interoperabilidade de C++ não estão disponíveis. Assemblies verificáveis não podem conter quaisquer funções não gerenciadas ou tipos de dados nativos, mesmo se eles não são referenciados pelo código gerenciado.
Apesar do uso da palavra "seguro", compilar aplicativos com /clr:safe não significa que não há nenhum bug; Isso apenas significa que o CLR pode verificar as configurações de segurança em tempo de execução.
Independentemente do tipo de montagem, as chamadas feitas a partir de assemblies gerenciados para DLLs nativas via P/Invoke irá compilar, mas podem falhar em tempo de execução dependendo das configurações de segurança.
.gif "Observação") Observação |
|---|
Há um cenário de codificação, que passará o compilador, mas o que resultará em um assembly não verificado: chamando uma função virtual por meio de uma instância de objeto usando o operador de resolução de escopo. For example: MyObj -> A::VirtualFunction();. |