Código puro e verificável (C + + / CLI)

Para a programação .NET, Visual C++ oferece suporte à criação de três tipos diferentes de componentes e de aplicativos: misturado, puro, e passível de verificação.Todos os três estão disponíveis com a opção de compilador /CLR (common Language Runtime Compilation) .

Comentários

Para obter mais informações sobre assemblies passíveis de verificação, consulte:

• Comparação de recursos misto, puro e verificável (C + + / CLI)

• Como: migrar para /clr: puro (C + + / CLI)

• Como: criar projetos C++ verificáveis (C + + / CLI)

• Como: migrar para /CLR: safe (C + + / CLI)

• Usando Assemblies verificáveis com SQL Server (C + + / CLI)

• Práticas recomendadas de segurança para C++

• Converting Projects from Mixed Mode to Pure Intermediate Language

Misturado (/clr)

Assemblies compilados com /clrmistos (), contém as partes gerenciados e não gerenciados, tornando possível para que usa recursos do .NET, mas ainda contêm código não gerenciado.Isso permite que aplicativos e componentes são atualizados para usar recursos do .NET sem exigir que o projeto inteiro ser reescrito.Usando Visual C++ para combinar gerenciado e não gerenciado é chamado esse modo Interoperabilidade C++.Para obter mais informações, consulte Mistos Assemblies (nativos e gerenciados) e Nativa e.Interoperabilidade..

Puro (/clr:pure)

Assemblies puros criados com /clr:pure() podem conter tipos de ambos e dados gerenciados, mas somente funções gerenciados.Como os assemblies mistos, assemblies puros permitem a interoperabilidade com as DLLs nativas por meio de P/Invoke (consulte Usando PInvoke Explicit no C++ (atributo DllImport)), mas os recursos de Interoperabilidade C++ não estão disponíveis.Além disso, os assemblies puros não podem exportar as funções que são acessíveis das funções nativos porque pontos de entrada em um uso puro do assembly __clrcall que chama a convenção.

Vantagens de /clr:pure

• Melhor desempenho: Porque os assemblies puros MSIL contém apenas, não há nenhuma função de ambos, e como consequência nenhuma transição gerenciado/não gerenciado é necessária.(As chamadas de função são feitas com P/Invoke uma exceção a essa regra.)

• Consciência Appdomain: As funções gerenciados e os tipos de dados CLR existem dentro de Application Domains, que afeta suas visibilidade e acessibilidade.Assemblies puros domínio (são cientes que o __declspec (AppDomain) é inferido para cada tipo) para que acessando os tipos e funcionalidade de outros componentes .NET é mais fácil e mais seguro.Como resultado, os conjuntos puros mais facilmente interoperam com outros componentes .NET que mistos de assemblies.

• Carregamento de não disco: Assemblies puros de memória podem ser carregado e passado mesmo.Isso é essencial para usar assemblys .NET como procedimentos armazenados.Isso difere dos assemblies mistos, que devido a uma dependência no Windows que carrega mecanismos, deve existir em disco para executar.

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

• Controllability host: Porque os assemblies puros MSIL, contém somente se comportam de maneira flexível e mais predizìvel dos assemblies mistos quando usados em aplicativos que hospedam o CLR e alteram o comportamento padrão.

Limitações de /clr:pure

Esta seção aborda os recursos que não está atualmente suportados por /clr:pure.

• Assemblies puros não podem ser chamados por funções não gerenciados.Como consequência assemblies puros não podem implementar interfaces COM ou callbacks de nativo a exposição.Assemblies puros não podem exportar funções através de __declspec (dllexport) ou arquivos de .DEF.Além disso, as funções declaradas com a convenção de __clrcall não podem ser importados através de __declspec (dllimport).Funções em um módulo nativo podem ser chamadas de um assembly, mas puro assemblies puros funções não podem expor nativo acessíveis, assim expor a funcionalidade em um assembly puro deve ser feita com as funções gerenciados em um assembly misturado.Consulte Como: migrar para /clr: puro (C + + / CLI) para maiores informações.

• As bibliotecas de ATL e de MFC não são suportadas pela compilação de pura para Visual C++.

• Puro.os netmodules não são aceitos como entrada ao vinculador Visual C++.No entanto, arquivos puros .obj de são aceitos pelo vinculador, e os arquivos de .obj contêm um supraconjunto de informações contido em netmodules.Consulte arquivos. netmodule como entrada de vinculador para maiores informações.

• Suporte COM de compilador (#import) não é suportado, porque isso ele deveria introduzir instruções não gerenciado no assembly puro.

• As opções de ponto flutuante para o alinhamento e a manipulação ajustáveis para tratamento não são. assemblies purosComo resultado, o __declspec alinhar () não pode ser usado.Isso apresenta alguns arquivos de cabeçalho, como fpieee.h, incompatível com /clr:pure.

• A função de GetLastError no PSDK pode fornecer comportamento indefinido para compilar com /clr:pure.

Verificável (/clr:safe)

A opção de compilador /clr:safe gera módulos passíveis de verificação, como aqueles escritas no Visual Basic e C#, conformando-se os requisitos que permitem que o tempo de execução (CLR) language runtime garante que o código não viola configurações de segurança atual.Por exemplo, se as configurações de segurança proibem um componente de gravada no disco, o CLR pode determinar se um componente verificável atendam ao critério antes de executar qualquer código.Não há suporte para CRT de assemblies passíveis de verificação.(O suporte de CRT está disponível para assemblies puros através de uma versão de pura MSIL da biblioteca em tempo de execução de C.)

Assemblies passíveis de verificação essas oferecem vantagens sobre assemblies puros mistos e:

• Segurança gerada.

• Algumas situações exigem-na (componentes SQL, por exemplo).

• As versões futuras do Windows exigirão sempre mais componentes e aplicativos ser passíveis de verificação.

Uma desvantagem é que os recursos de interoperabilidade C++ não estão disponíveis.Assemblies passíveis de verificação não podem conter quaisquer funções não gerenciado ou tipos de dados nativos, mesmo se não são referenciados pelo código gerenciado.

Independentemente do uso da palavra “com segurança”, criar aplicativos com /clr:safe não significa que não há nenhum erro; apenas significa que o CLR pode verificar as configurações de segurança em tempo de execução.

Independentemente do tipo de assembly, chamadas feitas de módulos (assemblies) gerenciados a DLL nativos através de P/Invoke compilarão, 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 transmitirão o compilador mas que resultará em um assembly não verificável: chamando uma função virtual através de um objeto métodos como exemplo usando o operador de resolução de escopo.Por exemplo: MyObj -> A::VirtualFunction();

Consulte também

Outros recursos

.NET programação no Visual C++