.NET Framework problems with Internet Explorer 11

  • Article

Caution

Update: The retired, out-of-support Internet Explorer 11 desktop application has been permanently disabled through a Microsoft Edge update on certain versions of Windows 10. For more information, see Internet Explorer 11 desktop app retirement FAQ.

Summary

If you’re having problems launching your legacy apps while running Internet Explorer 11, it’s most likely because Internet Explorer no longer starts apps that use managed browser hosting controls, like in .NET Framework 1.1 and 2.0.

To turn managed browser hosting controls back on

  1. 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.

  2. For 32-bit processes on x64 systems: Go to the HKLM\SOFTWARE\Wow6432Node\MICROSOFT\.NETFramework registry key and change the EnableIEHosting value to 1.

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 .NET Framework application compatibility, see Application compatibility in the .NET Framework.