Code pur et vérifiable

Mise à jour : novembre 2007

Pour la programmation sur .NET, Visual C++ prend en charge la création de trois types distincts de composants et d'applications : mixte, pur et vérifiable. Tous trois sont disponibles via l'option /clr (Compilation pour le Common Language Runtime) du compilateur.

Notes

Pour plus d'informations sur les assemblys vérifiables, voir :

• Comparaison entre les fonctionnalités mixte, pure et vérifiable

• Comment : effectuer une migration vers /clr:pure

• Comment : créer des projets C++ vérifiables

• Comment : effectuer une migration vers /clr:safe

• Utilisation d'assemblys vérifiables avec SQL Server

• Meilleures pratiques de sécurité pour C++

Mixte (/clr)

Les assemblys mixtes (compilés avec /clr), contiennent à la fois des parties non managées et managées, ce qui leur permet d'utiliser les fonctionnalités de .NET, tout en contenant du code non managé. Les applications et les composants peuvent ainsi être mis à jour pour pouvoir utiliser des fonctionnalités de .NET, sans qu'il soit nécessaire de réécrire le projet tout entier. L'utilisation de Visual C++ pour mélanger ainsi du code managé et du code non managé est appelée C++ Interop. Pour plus d'informations, consultez Assemblys mixtes (natif et managé) et Interopérabilité native et .NET.

Pur (/clr:pure)

Les assemblys purs (compilés avec /clr:pure) peuvent contenir des types de données à la fois natifs et managés, mais uniquement des fonctions managées. Tout comme les assemblys mixtes, les assemblys purs autorisent l'interopérabilité avec des DLL natives via P/Invoke (voir Utilisation d'un PInvoke explicite en C++ (attribut DllImport)), mais les fonctionnalités C++ Interop ne sont pas disponibles. En outre, les assemblys purs ne peuvent pas exporter les fonctions pouvant être appelées depuis des fonctions natives car les points d'entrée dans un assembly pur utilisent la convention d'appel __clrcall.

Avantages de /clr:pure

• Meilleures performances : les assemblys purs contenant uniquement du MSIL, il n'y a pas de fonctions natives et, par conséquent, aucune transition managée/non managée n'est nécessaire. (Les appels de fonction effectués via P/Invoke sont une exception à cette règle).

• Détection d'AppDomain : les fonctions managées et les types de données du CLR existent dans des Domaines d'application, ce qui affecte leur visibilité et leur accessibilité. Les assemblys purs reconnaissent les domaines (__declspec (appdomain est impliqué pour chaque type), l'accès à leurs types et à leurs fonctionnalités depuis d'autres composants .NET est donc plus facile et plus sûr. En conséquence, les assemblys purs interagissent plus facilement avec d'autres composants .NET que les assemblys mixtes.

• Chargement hors disque : les assemblys purs peuvent être chargés en mémoire et même transmis en continu. Cela est essentiel pour pouvoir utiliser des assemblys .NET comme des procédures stockées. Les assemblys mixtes, au contraire, doivent exister sur disque pour pouvoir s'exécuter, en raison de leur dépendance vis-à-vis des mécanismes de chargement de Windows.

• Réflexion: il n'est pas possible de refléter sur des fichiers exécutables mixtes, tandis que les assemblys purs prennent totalement en charge la réflexion. Pour plus d'informations, consultez Réflexion en C++.

• Contrôle de l'hôte : les assemblys purs contiennent uniquement du MSIL et se comportent donc de façon plus prévisible et plus souple que les assemblys mixtes lorsqu'on les utilise dans des applications qui hébergent le CLR et modifient son comportement par défaut.

Limitations de /clr:pure

Cette section couvre des fonctionnalités actuellement non prises en charge par /clr:pure.

• Les assemblys purs ne peuvent pas être appelés par des fonctions non managées. Ils ne peuvent donc pas implémenter d'interfaces COM ou exposer des rappels natifs. Les assemblys purs ne peuvent pas exporter de fonctions via des fichiers __declspec (dllexport) ou .DEF. En outre, les fonctions déclarées avec la convention __clrcall ne peuvent pas être importées via __declspec (dllimport). Les fonctions d'un module natif peuvent être appelées depuis un assembly pur, mais les assemblys purs ne peuvent pas exposer de fonctions appelables en natif, si bien que l'exposition des fonctionnalités dans un assembly pur doit avoir lieu via des fonctions managées dans un assembly mixte. Pour plus d'informations, consultez Comment : effectuer une migration vers /clr:pure.

• Les bibliothèques ATL et MFC ne sont pas prises en charge par la compilation en mode pur dans Visual C++ 2005.

• Les .netmodules purs ne sont pas acceptés comme entrées de l'éditeur de liens Visual C++. Toutefois, les fichiers .obj purs sont acceptés par l'éditeur de liens, et les fichiers .obj contiennent un sur-ensemble d'informations que contiennent les netmodules. Consultez Fichiers .netmodule en tant qu'entrée de l'Éditeur de liens pour plus d'informations.

• Le support COM du compilateur (#import) n'est pas pris en charge, car cela introduirait des instructions non managées dans l'assembly pur.

• Les options de virgule flottante pour l'alignement et la gestion des exceptions ne sont pas réglables pour les assemblys purs. En conséquence, __declspec(align) ne peut pas être utilisé. Certains fichiers d'en-tête, tels que fpieee.h, deviennent dès lors incompatibles avec /clr:pure.

• La fonction GetLastError dans le PSDK peut entraîner un comportement indéfini lors de la compilation avec /clr:pure.

Vérifiable (/clr:safe)

L'option du compilateur /clr:safe génère des assemblys vérifiables, comme ceux écrits en Visual Basic et en C#, en se conformant aux exigences qui permettent au Common Language Runtime (CLR) de garantir que le code ne viole aucun paramètre de sécurité actuel. Par exemple, si les paramètres de sécurité interdisent à un composant d'écrire sur le disque, le CLR peut déterminer si un composant vérifiable répond à ce critère avant d'exécuter du code. Il n'y a pas de prise en charge du CRT par les assemblys vérifiables. (La prise en charge du CRT est disponible pour les assemblys purs via une version MSIL pur de la bibliothèque Runtime C).

Les assemblys vérifiables offrent les avantages suivants par rapport aux assemblys purs et mixtes :

• Une meilleure sécurité.

• Certaines situations les exigent (les composants SQL, par exemple).

• Les futures versions de Windows exigeront de plus en plus que les composants et les applications soient vérifiables.

Le fait que les fonctionnalités d'interopérabilité C++ soient non disponibles est un inconvénient. Les assemblys vérifiables ne peuvent pas contenir de fonctions non managées ou de types de données natifs, même s'ils ne sont pas référencés par le code managé.

En dépit de l'utilisation du mot "safe", compiler des applications avec /clr:safe ne signifie pas qu'il n'y a pas de bogues ; cela signifie seulement que le CLR peut vérifier les paramètres de sécurité au moment de l'exécution.

Quel que soit le type d'assembly, les appels effectués depuis des assemblys managés vers des DLL natives via P/Invoke compileront, mais risqueront d'échouer à l'exécution selon le réglage des paramètres de sécurité.

Remarque :
Il existe un scénario de programmation qui passera le compilateur, mais le résultat sera un assembly invérifiable : il s'agit de l'appel à une fonction virtuelle via une instance d'objet à l'aide de l'opérateur de résolution de portée. Par exemple : MyObj -> A::VirtualFunction();.

Voir aussi

Autres ressources

Guide de programmation .NET