Considerations When Hosting an ActiveX Control on a Windows Form
Although Windows Forms have been optimized to host Windows Forms controls, you can still use ActiveX controls. Keep the following considerations in mind when planning an application that uses ActiveX controls:
Security The common language runtime has been enhanced with regard to code access security. Applications featuring Windows Forms can run in a fully trusted environment without issue and in a semi-trusted environment with most of the functionality accessible. Windows Forms controls can be hosted in a browser with no complications. However, ActiveX controls on Windows Forms cannot take advantage of these security enhancements. Running an ActiveX control requires unmanaged code permission, which is set with the SecurityPermissionAttribute.UnmanagedCode property. For more information about security and unmanaged code permission, see SecurityPermissionAttribute class.
Total Cost of Ownership ActiveX controls added to a Windows Form are deployed with that Windows Form in their entirety, which can add significantly to the size of the file(s) created. Additionally, using ActiveX controls on Windows Forms requires writing to the registry. This is more invasive to a user's computer than Windows Forms controls, which do not require this.
Note
Working with an ActiveX control requires the use of a COM interop wrapper. For more information, see COM Interoperability in Visual Basic and Visual C#.
Note
If the name of a member of the ActiveX control matches a name defined in the .NET Framework, then the ActiveX Control Importer 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.
See Also
Tasks
How to: Add ActiveX Controls to Windows Forms
Reference
Controls and Programmable Objects Compared in Different Languages and Libraries