Considérations sur l'hébergement d'un contrôle ActiveX dans un Windows Form

Mise à jour : novembre 2007

Bien que les Windows Forms aient été optimisés pour l'hébergement de contrôles Windows Forms, il est toujours possible d'y inclure des contrôles ActiveX. Prenez les éléments suivants en compte lors de la planification d'une application qui utilise des contrôles ActiveX :

  • Sécurité   Le Common Language Runtime a été optimisé sur le plan de la Sécurité d'Accès du Code. Les applications recourant aux Windows Forms peuvent s'exécuter sans problème dans un environnement de niveau de confiance total et, dans un environnement de niveau de confiance partiel, avec la plupart des fonctionnalités disponibles. L'hébergement des contrôles Windows Forms dans un navigateur ne présente aucun problème. Toutefois, les contrôles ActiveX dans les Windows Forms ne peuvent pas tirer parti de ces améliorations de sécurité. L'exécution d'un contrôle ActiveX requiert une autorisation de code non managé, définie avec la propriété SecurityPermissionAttribute.UnmanagedCode. Pour plus d'informations sur la sécurité et l'autorisation de code non managé, consultez la classe SecurityPermissionAttribute.

  • Coût total de propriété (TCO, Total Cost of Ownership)   Les contrôles ActiveX ajoutés à un Windows Form sont déployés sur ce Windows Form dans son intégralité, ce qui est susceptible d'accroître considérablement la taille du ou des fichiers créés. En outre, l'utilisation de contrôles ActiveX sur des Windows Forms exige une écriture dans le Registre. Les répercussions sur l'ordinateur de l'utilisateur sont donc plus grandes qu'avec des Windows Forms, qui ne nécessitent pas d'écriture dans le Registre.

    Remarque :

    L'utilisation d'un contrôle ActiveX requiert l'utilisation d'un wrapper COM Interop. Pour plus d'informations, consultez Interopérabilité COM dans Visual Basic et Visual C#.

    Remarque :

    Si le nom d'un membre du contrôle ActiveX correspond à un nom défini dans le .NET Framework, l'importateur de contrôles ActiveX fera précéder le nom du membre de Ctl lors de la création de la classe dérivée AxHost. Par exemple, si votre contrôle ActiveX comporte un membre nommé Layout, il est renommé CtlLayout dans la classe dérivée de AxHost, car l'événement Layout est défini dans .NET Framework.

Voir aussi

Tâches

Comment : ajouter des contrôles ActiveX aux Windows Forms

Référence

Comparaison des contrôles et des objets programmables dans différents langages et dans différentes bibliothèques

Autres ressources

Sécurité d'accès du code

Placement de contrôles dans les Windows Forms

Contrôles Windows Forms