Latest Runtime Loaded when Hosting Managed Controls in IE

Latest Runtime Loaded when Hosting Managed Controls in IE

  • Comments 5

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_MACHINE\Software\Microsoft\.NETFramework\policy\Upgrades. 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.

Leave a Comment
  • Please add 1 and 8 and type the answer here:
  • Post
  • I'm going to take a stab at this and ask if this is for security reasons. I can imagine that you are trying to prevent someone from controlling the runtime in order to execute their code in a less-secure version of the runtime. For instance, all of the security fixed provided with the 1.1 update could be bypassed if you could instruct your IE hosted control to load in the 1.0 runtime?
  • Tobin, the reason I was given was that if the client process - say iexplore.exe - loaded .NET 1.1 and then browsed to a page with a managed hosted control requiring .NET 2.0, the control would fail to load until iexplore.exe was restarted. This could affect many open windows or tabs.

    CAS in .NET 1.0 is still strong - perhaps a little too strong. Regarding the Internet_Zone, several of us when I was still an outsider met in a newsgroup and asked for the PermissionSet to be changed because it was seriously limiting. A couple problems with AppDomain.GetData and SqlConnection were fixed but I'm not aware of any major deficiencies.
  • There are major pros and cons to this situation, which seriously impact the design of extensible software which has security requirements beyond the out-of-the-box story.

    I should work up a complete blog article talking about this, but briefly, we're in a bit of a cleft stick.

    Side-by-side CLRs mean that you can install a new CLR and old applications that depend on the old CLR are guaranteed to not break. But that means that each CLR must have its own tree of policy. Now when you throw extensible applications into the mix, applications which may have customizations that require the latest CLR, you run the risk of breaking applications which require the OLD CLR's security policy.

    We worked around this in VSTO with a series of egregious hacks to ensure that existing VSTO 2003 customizations continue to work when the 2005 CLR is installed.
  • I have seen the same happening with a .NET based Outlook addIn, NewsGator. Because it runs inside the Outlook process it doesn't get a chance to control which runtime is loaded. Because it is not still compatible with 2.0 you need to write an OUTLOOL.EXE.Config file to make it work. In the end, it is a real mess for a normal user.
  • Diego, does NewsGator have that documented somewhere? You're right that for normal users this is a problem since many may not even realize that the add-in is managed or what managed code even is to the point they know what to do to work around the issue.

    I recommend that you email NewsGator Support. I have twice now about a couple of issues with their Web Edition and they respond quickly and are very helpful.
Page 1 of 1 (5 items)