Partager via

Considérations relatives à l’hébergement d’un contrôle ActiveX sur un Windows Form

  • Article

Bien que Windows Forms ait été optimisé pour héberger des contrôles Windows Forms, vous pouvez toujours utiliser des contrôles ActiveX. Gardez à l’esprit les considérations suivantes lors de la planification d’une application qui utilise des contrôles ActiveX :

  • Sécurité Le Common Language Runtime a été amélioré en ce qui concerne la sécurité de l’accès au code. Les applications avec Windows Forms peuvent s’exécuter dans un environnement entièrement approuvé sans problème et dans un environnement semi-approuvé avec la plupart des fonctionnalités accessibles. Les contrôles Windows Forms peuvent être hébergés dans un navigateur sans complications. Toutefois, les contrôles ActiveX sur Windows Forms ne peuvent pas tirer parti de ces améliorations de sécurité. L’exécution d’un contrôle ActiveX nécessite une autorisation de code non managée, qui est définie avec la propriété SecurityPermissionAttribute.UnmanagedCode. Pour plus d’informations sur la sécurité et l’autorisation de code non managé, consultez SecurityPermissionAttribute.

  • coût total de possession contrôles ActiveX ajoutés à un Windows Form sont déployés avec ce Windows Form dans leur intégralité, ce qui peut ajouter considérablement à la taille des fichiers créés. En outre, l’utilisation de contrôles ActiveX sur Windows Forms nécessite l’écriture dans le Registre. Cela est plus invasif pour l’ordinateur d’un utilisateur que les contrôles Windows Forms, qui ne nécessitent pas cela.

    Note

    L’utilisation d’un contrôle ActiveX nécessite l’utilisation d’un wrapper COM Interop. Pour plus d’informations, consultez l'interopérabilité COM en Visual Basic et Visual C#.

    Note

    Si le nom d’un membre du contrôle ActiveX correspond à un nom défini dans le .NET Framework, l’importateur de contrôle ActiveX préfixe le nom du membre avec Ctl lorsqu’il crée la classe dérivée AxHost. Par exemple, si votre contrôle ActiveX a un membre nommé Layout, il est renommé CtlLayout dans la classe dérivée d’AxHost, car l’événement Layout est défini dans le .NET Framework.

Voir aussi