Quelle est la différence entre une applet .NET et un contrôle ActiveX intégré à IE

Question

J'ai trouvé sur le Web des articles sur les applets .Net et je me demandais en quoi il diffère d'un contrôle ActiveX (créé à l'aide d'un langage .Net)? (pour clarifier, cela concerne les applets qui s'exécutent dans un navigateur Web)

(La différence est-elle: les contrôles ActiveX écrits dans un langage .Net sont appelés des applets .Net?)

Y a-t-il des avantages à utiliser l'un par rapport à l'autre?

En outre, en quoi Microsoft fait-il référence à cette technologie? (Une recherche sur MSDN n'apporte rien appelé. Net Applets!)

ps: d'après ce que je peux voir, les contrôles ActiveX doivent être enregistrés COM, contrairement aux applets .Net. De plus, dans la page Web, les contrôles activeX sont référencés à l'aide de leur CLSID, alors que les applets .NET semblent être référencés par un nom complet (chemin d'accès, nom de la DLL, espace de noms et classe)

Answer 1

Les contrôles ActiveX sont simplement des objets COM qui implémentent au minimum IUnknown. Les versions récentes d'IE ont également commencé à exiger que l'objet implémente IObjectSafety. Pour faire quoi que ce soit d’utile, l’objet doit également implémenter d’autres interfaces Ole, telles que IDispatch, IOleObject, etc. L’objet doit pouvoir être créé via CoCreateInstance (), ce qui signifie que vous devez enregistrez d’une manière ou d’une autre avec le registre. Vous n'avez pas besoin d'utiliser un GUID dans la balise, vous pouvez également utiliser le AppId si vous en enregistrez un.

Vous pouvez également écrire du code managé et l'exécuter dans IE. La façon dont cela fonctionne est que le CLR enregistre un filtre MIME quand il est installé. Ensuite, lorsque IE voit que vous envoyez quelque chose du type mime approprié, il transmet le code au CLR. Le CLR met le code en sandbox dans la mesure où il ne dispose que d'autorisations Internet. Par conséquent, il ne peut pas faire tout ce que le framework expose. Vous devrez vérifier la documentation spécifique pour savoir ce qui peut et ne peut pas être fait dans cette zone de sécurité.

Quelques compromis:

Facilité d’installation: les contrôles ActiveX vous obligent à tout ranger dans un fichier .CAB avec un fichier .INI qui décrit les exigences d’installation de manière assez cryptique. Si vous devez installer des dépendances supplémentaires avec vos modules (telles que des dlls ATL / MFC ou d'autres modules tiers), cela devient assez compliqué. Avec le module .net, il vous suffit de l'envoyer avec le bon type MIME, mais vous devez vous assurer que vos utilisateurs disposent de la bonne version du framework (que vous pouvez vérifier via la chaîne d'agent d'utilisateur sur votre site Web).

Sécurité: les contrôles ActiveX ne sont que du code natif s'exécutant sur le système des utilisateurs. Ils peuvent donc théoriquement faire ce qu'ils veulent. Dans la pratique, LoRIE limite ce problème dans de nombreux cas et vous devez effectuer plusieurs opérations spéciales, telles que l’accès au registre et aux systèmes de fichiers (voir Comprendre et utiliser le mode protégé ).

Threading: étant donné que les contrôles ActiveX s'exécutent sur le thread d'interface utilisateur des navigateurs, vous devez vous assurer de ne pas effectuer de longues opérations de blocage sur ce thread. Vous devez donc effectuer vous-même les threads. Si votre longue opération de blocage manipule le DOM, vous devez définir vous-même les interfaces IHTMLxxx, en utilisant GIT ou COM Marshalling fonctions . Je ne sais pas si les applets .net s'exécutent sur le thread d'interface utilisateur des navigateurs ou non, mais il est plus facile à gérer en C #, j'en suis sûr.

Objets du navigateur: si vous souhaitez utiliser des objets IE / Shell dans votre extension gérée, vous devez écrire vous-même l'interopérabilité, car Framework ne permet pas d'encapsuler ces interfaces dans des objets gérés. Consultez http://pinvoke.net pour obtenir un peu d'aide pour démarrer.

Compatibilité: il existe des problèmes d’hébergement de différentes versions du moteur d’exécution dans le même processus. Jusqu'à récemment, ce n'était pas possible du tout, mais je pense qu'avec les versions 3.x, cela a commencé à devenir possible dans une certaine mesure. Le résultat est que si vous ciblez .net 2.0 et que quelqu'un d'autre a déjà chargé .net 1.0 dans le cadre de l'extension de leur navigateur, vous perdez. En général, IE et Windows Shell ne prennent pas en charge les extensions gérées. Ce filtre MIME peut être une exception notable, mais sachez qu'il peut y avoir des problèmes.

Answer 2

"Contrôle ActiveX (créé à l'aide d'un langage .Net)" et " applet .NET " sont à la fois en argot pour "l’assemblage .NET hébergé dans IE".

En fait, les assemblys .NET peuvent être hébergés dans diverses applications. Voir:

Création d'un hôte pour l'exécution du langage commun .NET

Answer 3

Les contrôles ActiveX n’ont pas les mêmes restrictions de sécurité que les applets .NET, ce qui peut constituer un avantage ou un inconvénient selon ce que vous souhaitez faire. Les applets .NET sont en général plus faciles à développer, vous créez ActiveX avec VB6 ou C ++.