deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-12 13:27:23 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Merge pull request #3245 from MicrosoftDocs/master

Browse Source 
Publish 7/7/2020 10:30 AM PT
This commit is contained in:
Tina Burden 2020-07-07 10:47:56 -07:00 committed by GitHub
commit 3ecd8a8c18
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 10 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
browsers/internet-explorer/ie11-deploy-guide/net-framework-problems-with-ie11.md
View File

@ -16,6 +16,9 @@ ms.date: 07/27/2017
# .NET Framework problems with Internet Explorer 11
## 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**
@ -24,11 +27,14 @@ If you’re having problems launching your legacy apps while running Internet Ex
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**.
For more information, see the [Web Applications](https://go.microsoft.com/fwlink/p/?LinkId=308903) section of the Application Compatibility in the .NET Framework 4.5 page.
## 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](/dotnet/framework/migration-guide/application-compatibility).