INFO: Native Versus COM-Callable .NET Controls in Internet Explorer (317346)

MORE INFORMATION

Most developers prefer to host a .NET UserControl by using the overloaded syntax for the OBJECT tag, as follows

<OBJECT id="Obj1" classid="Assembly.dll#Full.Namespace.ControlName">
				

where "Assembly.dll" is a relative, virtual, or absolute path to the .NET assembly that contains your control, and "Full.Namespace.ControlName" is a fully-qualified namespace reference to the control that you want to host.

This usage is very powerful, because .NET assemblies install by using the new zero-impact Fusion technology, which enables assembly installation without the need to write any secondary information to the user's registry. To update the control is as simple as downloading a new copy (which the Runtime takes care of automatically); removing it from the computer is as simple as removing the assembly from the Fusion download cache.

However, because of security concerns, this usage has an important limitation: You can load only controls hosted on a Web server. Any attempt to load a UserControl in Internet Explorer from the file system or the global assembly cache will be unsuccessful. This can hinder you if your application runs locally from a CD-ROM or the user's hard disk, or if business requirements dictate that the controls that you want to use be placed in the global assembly cache.

In such cases, you can compile your control to support COM interop, and host it within Internet Explorer as if it were a classic ActiveX control. This requires you to assign a globally unique identifier (GUID) to each COM-callable object by using the GuidGen.exe utility and the GuidAttribute metadata attribute defined in the .NET Framework. After that, you can use the Microsoft Windows Installer (MSI) to install your assembly on the user's target computer and register it as a COM object.