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

  • Article

Bien que les Windows Forms aient été optimisés pour héberger des contrôles Windows Forms, vous pouvez néanmoins 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é d’accès du code. Les applications recourant aux Windows Forms peuvent fonctionner sans problème dans un environnement totalement fiable et dans un environnement partiellement fiable avec la plupart des fonctionnalités disponibles. Les contrôles Windows Forms peuvent être hébergés dans un navigateur sans aucune complication. Cependant, les contrôles ActiveX dans les Windows Forms ne tirent pas 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 SecurityPermissionAttribute.UnmanagedCode propriété. Pour plus d’informations sur la sécurité et l’autorisation de code non managé, consultez SecurityPermissionAttribute.

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

    Remarque

    L’utilisation d’un contrôle ActiveX nécessite l’utilisation d’un wrapper COM interop. Pour plus d’informations, consultez Interopérabilité COM en 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ôle ActiveX préfixe le nom du membre avec Ctl lorsqu’il crée la AxHost classe dérivée. 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