ActiveX Control Importer pour Windows Forms (Aximp.exe)
Mise à jour : novembre 2007
L'importateur de contrôles ActiveX convertit les définitions de types d'une bibliothèque de types COM associées à un contrôle ActiveX en un contrôle Windows Forms.
Windows Forms peut héberger uniquement des contrôles Windows Forms, c'est-à-dire, des classes dérivées de Control. Aximp.exe génère une classe wrapper associée à un contrôle ActiveX qui peut être hébergée dans un Windows Form. Cela vous permet d'utiliser la même prise en charge au moment du design et la même méthodologie de programmation que pour d'autres contrôles Windows Forms.
Pour héberger le contrôle ActiveX, vous devez générer un contrôle wrapper qui dérive de AxHost. Ce contrôle wrapper contient une instance du contrôle ActiveX sous-jacent. Il sait comment communiquer avec le contrôle ActiveX, mais il se présente comme un contrôle Windows Forms. Le contrôle ainsi généré héberge le contrôle ActiveX dont il expose les propriétés, les méthodes et les événements comme si ces derniers lui appartenaient.
aximp [options]{file.dll | file.ocx}
Notes
Argument |
Description |
|---|---|
fichier |
Nom du fichier source contenant le contrôle ActiveX à convertir. La valeur de cet argument doit présenter l'extension .dll ou .ocx. |
Option |
Description |
|---|---|
/delaysign |
Spécifie à Aximp.exe que le contrôle résultant doit être signé à l'aide du processus de signature différée. Vous devez spécifier cette option avec /keycontainer:, /keyfile: ou /publickey:. Pour plus d'informations sur le processus de signature différée, consultez Temporisation de signature d'un assembly. |
/help |
Affiche la syntaxe et les options de commande de l'outil. |
/keycontainer:NomConteneur |
Signe le contrôle résultant avec un nom fort en utilisant la paire de clés publique/privée présente dans le conteneur de clé spécifié par NomConteneur. |
/keyfile:NomFichier |
Signe le contrôle résultant avec un nom fort en utilisant la paire de clés publique/privée officielle de l'éditeur présente dans NomFichier. |
/nologo |
Supprime l'affichage de la bannière de démarrage Microsoft. |
/out:NomFichier |
Spécifie le nom de l'assembly à créer. |
/publickey:NomFichier |
Signe le contrôle résultant avec un nom fort à l'aide de la clé publique présente dans le fichier spécifié par NomFichier. |
/silent |
Supprime l'affichage des messages indiquant la réussite des opérations. |
/source |
Génère le code C# source pour le wrapper Windows Forms. |
/verbose |
Spécifie le mode documenté ; affiche des informations supplémentaires sur la progression de l'opération. |
/? |
Affiche la syntaxe et les options de commande de l'outil. |
Aximp.exe convertit toute une bibliothèque de types de contrôles ActiveX à la fois et produit un ensemble d'assemblys contenant les métadonnées du Common Language Runtime et l'implémentation des contrôles pour les types définis dans la bibliothèque de types d'origines. Les fichiers générés sont nommés conformément à la règle suivante :
Proxy du Common Language Runtime pour les types COM : progid.dll
Proxy Windows Forms pour les contrôles ActiveX (où Ax est l'abréviation de ActiveX) : Axprogid.dll
.gif "Remarque") Remarque : |
|---|
Si le nom d'un membre du contrôle ActiveX correspond à un nom défini dans le .NET Framework, Aximp.exe fait précéder le nom du membre de « Ctl » lorsqu'il crée la classe dérivée AxHost. Par exemple, si votre contrôle ActiveX possède un membre nommé « Layout », il est renommé « CtlLayout » dans la classe dérivée AxHost car l'événement Layout est défini dans le .NET Framework. |
Vous pouvez examiner ces fichiers générés à l'aide d'outils, tels que MSIL Disassembler (Ildasm.exe).
L'utilisation d'Aximp.exe pour générer un assembly .NET pour le contrôle ActiveX WebBrowser (shdocvw.dll) n'est pas prise en charge.
L'exécution d'Aximp.exe sur shdocvw.dll créera toujours un autre fichier nommé shdocvw.dll dans le répertoire à partir duquel l'outil est exécuté. Si le fichier généré est placé dans le répertoire Documents and Settings, cela perturbe le fonctionnement de Microsoft Internet Explorer et de l'Explorateur Windows. Lors du redémarrage de l'ordinateur, Windows recherche une copie de shdocvw.dll dans le répertoire Documents and Settings, au lieu de commencer la recherche dans le répertoire System32. Il utilise la copie trouvée dans Documents and Settings et tente de charger les wrappers managés. Internet Explorer et l'Explorateur Windows ne fonctionnent pas correctement car ils s'appuient sur le moteur de rendu figurant dans la version de shdocvw.dll qui se trouve dans le répertoire System32. Si ce problème survient, supprimez la copie de shdocvw.dll qui se trouve dans le répertoire Documents and Settings, puis redémarrez votre ordinateur.
L'utilisation d'Aximp.exe avec shdocvw.dll pour créer un assembly .NET en vue de son utilisation dans le développement d'une application peut également poser problème Dans ce cas, votre application chargera la version système de shdocvw.dll ainsi que la version générée, et pourrait donner la priorité à la version système. Dans ce cas, lorsque vous essayez de charger une page Web dans le contrôle WebBrowser ActiveX, une boîte de dialogue Ouvrir/Enregistrer peut s'afficher. Si l'utilisateur clique sur Ouvrir, la page Web s'ouvre dans Internet Explorer. Cela ne se produit que sur les ordinateurs exécutant Internet Explorer version 6 ou antérieure. Pour éviter ce problème, utilisez le contrôle WebBrowser managé ou utilisez Visual Studio pour générer le fichier shdocvw.dll managé, comme décrit dans Comment : ajouter des références aux bibliothèques de types.
Exemple
La commande suivante génère MediaPlayer.dll et AxMediaPlayer.dll pour le contrôle Media Player msdxm.ocx.
aximp c:\systemroot\system32\msdxm.ocx