I previously mentioned how I worked on a project that deploys managed applications via the Internet or an intranet. Some of my initial research was into hosting managed controls in Internet Explorer. The .NET Framework 1.0 originally granted no permissions to the Internet_Zone code group so we had to deploy a small setup that used a custom
System.Configuration.Install.Installer class to modify the machine policy.
Now — almost 2 versions later — it’s quite likely that you have several different managed runtimes installed onto your machine. Normally, mscoree.dll — the entry point for managed executables — will load the CLR, or simply “runtime”, that corresponds to the Framework assemblies referenced in your assembly’s manifest, i.e. if you reference System.dll version 1.0.3300.0 then mscoree.dll will attempt to load .NET v1.0.3705. If .NET v1.0.3705 is not found, then a redirection policy is used, which is described in the registry at HKEY_LOCAL_MACHINESoftwareMicrosoft.NETFrameworkpolicyUpgrades. Currently, if you have .NET v1.1.4322 installed it will be loaded in lieu of .NET v1.0.3705, but if you have .NET v2.0.50215 or one of our .NET 2.0 CTPs installed it will take over all redirection. As an application developer, you can control whether your application is loaded in a different runtime and which runtimes are supported by using the
<requiredRuntime/> element for applications targeting .NET v1.0.3705 and the
<supportedRuntime/> element for later versions.
For managed hosted controls in Internet Explorer, however, the latest runtime is always loaded into the client process. The
<startup/> element is also ignored so you cannot control which runtime is loaded or which runtimes are supported. This means that if your hosted control requires additional permissions based on host evidence or strong name identity evidence then you must ensure your code group is added to the latest runtime available on the system and, of course, that your hosted control is compatible with new runtimes.