Aximp.exe (Windows Forms ActiveX Control Importer)
The ActiveX Control Importer converts type definitions in a COM type library for an ActiveX control into a Windows Forms control.
Windows Forms can only host Windows Forms controls — that is, classes that are derived from Control. Aximp.exe generates a wrapper class for an ActiveX control that can be hosted on a Windows Form. This allows you to use the same design-time support and programming methodology applicable to other Windows Forms controls.
To host the ActiveX control, you must generate a wrapper control that derives from AxHost. This wrapper control contains an instance of the underlying ActiveX control. It knows how to communicate with the ActiveX control, but it appears as a Windows Forms control. This generated control hosts the ActiveX control and exposes its properties, methods, and events as those of the generated control.
This tool is automatically installed with Visual Studio. To run the tool, use Visual Studio Developer Command Prompt or Visual Studio Developer PowerShell.
At the command prompt, type the following:
Syntax
aximp [options]{file.dll | file.ocx}
Remarks
| Argument | Description |
|---|---|
| file | The name of the source file that contains the ActiveX control to convert. The file argument must have the extension .dll or .ocx. |
| Option | Description |
|---|---|
/delaysign |
Specifies to Aximp.exe to sign the resulting control using delayed signing. You must specify this option with either the /keycontainer:, /keyfile:, or /publickey: option. For more information on the delayed signing process, see Delay Signing an Assembly. |
/help |
Displays command syntax and options for the tool. |
/keycontainer: containerName |
Signs the resulting control with a strong name using the public/private key pair found in the key container specified by containerName. |
/keyfile: filename |
Signs the resulting control with a strong name using the publisher's official public/private key pair found in filename. |
/nologo |
Suppresses the Microsoft startup banner display. |
/out: filename |
Specifies the name of the assembly to create. |
/publickey: filename |
Signs the resulting control with a strong name using the public key found in the file specified by filename. |
/rcw: filename |
Uses the specified runtime callable wrapper instead of generating a new one. You may specify multiple instances. The current directory is used for relative paths. For more information, see Runtime Callable Wrapper. |
/silent |
Suppresses the display of success messages. |
/source |
Generates C# source code for the Windows Forms wrapper. |
/verbose |
Specifies verbose mode; displays additional progress information. |
/? |
Displays command syntax and options for the tool. |
Aximp.exe converts an entire ActiveX Control type library at one time and produces a set of assemblies that contain the common language runtime metadata and control implementation for the types defined in the original type library. The generated files are named according to the following pattern:
Common language runtime proxy for COM types: progid.dll
Windows Forms proxy for ActiveX controls (where Ax signifies ActiveX): Axprogid.dll
Note
If the name of a member of the ActiveX control matches a name defined in the .NET Framework, Aximp.exe will prefix the member name with "Ctl" when it creates the AxHost derived class. For example, if your ActiveX control has a member named "Layout," it is renamed "CtlLayout" in the AxHost derived class because the Layout event is defined within the .NET Framework.
You can examine these generated files with tools such as Ildasm.exe (IL Disassembler).
Using Aximp.exe to generate a .NET assembly for the ActiveX WebBrowser control (shdocvw.dll) is not supported.
When you run Aximp.exe over shdocvw.dll, it will always create another file named shdocvw.dll in the directory from which the tool is run. If you place this generated file in the Documents directory, it can cause problems for Windows Explorer. When the computer is rebooted, Windows looks in the Documents directory before the system32 directory to find a copy of shdocvw.dll. It will use the copy it finds in Documents and attempt to load the managed wrappers. Windows Explorer won't function properly because it relies on the rendering engine in the version of shdocvw.dll located in the system32 directory. If this problem occurs, delete the copy of shdocvw.dll in the Documents directory and reboot the computer.
Example
The following command generates MediaPlayer.dll and AxMediaPlayer.dll for the Media Player control msdxm.ocx.
aximp c:\systemroot\system32\msdxm.ocx
