Código puro e verificável

  • Artigo

Para .NET Programming, Visual C++ oferece suporte à criação de três tipos diferentes de componentes e aplicativos: misto, puro e verificável.Todos os três estão disponível por meio de o CLR (ComComummon Idioma Tempo de execução ComComumpilation) opção do compilador.

Comentários

Para obter mais informações sobre assemblies verificáveis, consulte:

Misto (/ clr)

Assemblies mistos (compilados com /clr), contêm ambos não gerenciados e gerenciados partes, tornando possível para que eles possam usar os recursos do .NET, mas ainda contêm código não gerenciado. Isso permite que os aplicativos e componentes a ser atualizado usar recursos .NET sem exigir que o projeto inteiro ser reescrito.Usando o Visual C++ para misturar código gerenciado e dessa maneira é chamada de interoperabilidade de C++.Para obter mais informações, consulte Misto (nativo e gerenciado) assemblies e Nativo e interoperabilidade .NET.

Puro (/ clr: puro)

Assemblies puros (compilados com /clr:pure) pode conter os dois tipos de dados nativo e gerenciado, mas somente funções gerenciadas. Como os assemblies mistos, assemblies puros permitem que interoperabilidade com DLLs nativo por meio de P/Invoke (consulte Usar PInvoke Explicit no C++ (atributo DllImport)), mas os recursos de interoperabilidade C++ não estão disponível. Além disso, assemblies puros não é possível exportar funções que podem ser chamados de nativo funciona como pontos de entrada em um assembly puro usam o __clrcall convenção de chamada.

Vantagens do/CLR: puro

  • Melhor desempenho: Como assemblies puros contêm apenas MSIL, há não há funções nativas e, portanto, sem transições gerenciado/não gerenciado são necessárias.(Chamadas de função feitas por meio de P/Invoke são uma exceção a essa regra.)

  • Reconhecimento de AppDomain: gerenciado funções e tipos de dados CLR existirem dentro de Domínios de aplicativo, que afeta sua visibilidade e acessibilidade. Assemblies puros são sensíveis ao domínio (__declspec(Appdomainestá implícito) para cada tipo) então acessar seus tipos e a funcionalidade de outros componentes do .NET é mais fácil e mais seguro. sistema autônomo resultado, assemblies puros mais com com facilidade interoperam com outros componentes .NET que sistema autônomo assemblies mistos.

  • Carregamento do disco não: Puros assemblies podem ser carregados na memória e até mesmo em fluxo.Isso é essencial para o uso de assemblies .NET sistema autônomo procedimentos armazenados.Isso difere do assemblies mistos, que, devido a uma dependência no Windows, carregando mecanismos, deve existir no disco para ser executado.

  • Reflexão: Não é possível refletir sobre misto executáveis, enquanto os assemblies puros oferecem suporte completo de reflexão.Para obter mais informações, consulte Reflexão em C++.

  • Host Controllability: Como assemblies puros contêm apenas MSIL, elas se comportam mais previsível e flexível que misto módulos (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 retornos de chamada nativo.Assemblies puros não é possível exportar funções via __declspec(dllexport) ou .def arquivos.Além disso, não não possível importar funções declaradas com a convenção __clrcall via __declspec(dllimport).Funções em um módulo nativo podem ser chamadas a partir de um assembly puro, mas assemblies puros não podem expor funções podem ser chamadas nativos, para que expor a funcionalidade em um assembly puro deve ser feita por meio de funções gerenciadas em um conjunto misto.Consulte Como: Migrar para o/CLR: puro para obter mais informações.

  • Bibliotecas ATL e MFC não são suportadas pelo modo puro compilation em Visual C++ 2005.

  • Puro.netmodules não são aceitos sistema autônomo entrada para o vinculador Visual C++.No entanto, arquivos .obj puro são aceitos pelo vinculador, e os arquivos .obj contêm um subconjunto de informações contidas no netmodules.Consulte Entrada de arquivos como vinculador .netmodule para obter mais informações.

  • Compilador COM suporte (# Import) não é suportado, pois isso introduziria instruções não gerenciadas no assembly puro.

  • Opções de alinhamento e a manipulação de exceção não são ajustáveis para assemblies puros de ponto flutuante.sistema autônomo resultado, __declspec(alinhar) não pode ser usado.Isso apresenta alguns arquivos de cabeçalho, sistema autônomo fpieee.h, incompatível com/CLR: puro.

  • A função GetLastError o PSDK pode fornecer um comportamento indefinido durante a compilação de /clr:pure.

Pode ser verificada (/ clr:safe)

The /clr:safe opção do compilador gera assemblies verificáveis, como aqueles escritos em Visual Basic e translation from VPE for Csharp, em conformidade com requisitos que permitem que o common linguagem tempo de execução (CLR) garantir que o código não violem as configurações de segurança corrente. Por exemplo, se as configurações de segurança proíbem 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 CRT para assemblies verificáveis.(CRT suporte está disponível para assemblies puros por meio de uma versão de MSIL puro da biblioteca de tempo de execução C).

Assemblies verificáveis oferecem essas vantagens sobre assemblies puros e mistos:

  • Maior segurança.

  • Algumas situações exijam (componentes SQL, por exemplo).

  • Cada vez mais exigirá futuras versões do Windows, componentes e aplicativos seja verificável.

Uma desvantagem é que os recursos de interoperabilidade C++ não estão disponível.Assemblies verificáveis não podem conter qualquer funções não gerenciadas ou tipos de dados nativo, mesmo se eles não são citados por código gerenciado.

Apesar do uso da palavra "seguro", compilar aplicativos com**/clr:safe** não significa que não há nenhum bugs; significa apenas que o CLR pode verificar as configurações de segurança em time de execução.

Independentemente do tipo de montagem, chamadas feitas a partir de módulos (assemblies) gerenciado para DLLs nativas via P/Invoke irão compilar, mas podem falhar em tempo de execução dependendo das configurações de segurança.

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.Por exemplo: MyObj -> A::VirtualFunction();.

Consulte também

Outros recursos

Guia de programação .NET