Managed hosting controls are disabled in Internet Explorer from the .NET Framework 4

Applies to: Internet Explorer 10Internet Explorer 11Internet Explorer 9


Internet Explorer cannot start applications that use managed browser hosting controls.


This is by design to disable IEHost in Microsoft .NET Framework 4 or later versions.


To work around this issue, you can enable Internet Explorer to use managed browser hosting controls again by setting the EnableIEHosting value to 1. To do this, use one of the following methods:
  • For x86 systems or for 64-bit processes on x64 systems: Go to the HKLM\SOFTWARE\MICROSOFT\.NETFramework registry key and change the EnableIEHosting value to 1.
  • For 32-bit processes on x64 systems: Go to the HKLM\SOFTWARE\Wow6432Node\MICROSOFT\.NETFramework registry key and change the EnableIEHosting value to 1.

Note Running parts of an application in this mode is a well-known security vulnerability. Customers should be aware of the risks that are described in this article. There are no tested and documented ways to reduce the risks. There are many alternatives, such as Microsoft ClickOnce applications, XAML browser applications (XBAPs), and Microsoft Silverlight, that can provide you better security and scalability.

More Information

IEHost is a Microsoft .NET Framework 1.1-based technology that provides a better model than ActiveX controls to host controls within the browser. The IEHost controls are lightweight and are operated under the .NET security model where they are operated inside a sandbox.

From the .NET Framework 4, we remove the IEHost.dll file for the following reasons:
  • IEHost/HREF-EXE-style controls are exposed to the Internet. This poses a high security risk, and most customers who install the Framework are benefiting very little from this security risk. 
  • Managed hosting controls and invoking random ActiveX controls may be unsafe, and this risk cannot be countered in the .NET Framework. Therefore, the ability to host is disabled. We strongly suggest that IEHost should be disabled in any production environment.
  • Potential security vulnerabilities and assembly versioning conflicts in the default application domain. By relying on COM Interop wrappers to load your assembly, it is implicitly loaded in the default application domain. If other browser extensions do the same function, they have the risks in the default application domain such as disclosing information, and so on. If you are not using strong-named assemblies as dependencies, type loading exceptions can occur. You cannot freely configure the common language runtime (CLR), because you do not own the host process, and you cannot run any code before your extension is loaded.
For more information about the EnableIEHosting value, go to the following Microsoft websites: