To solve problems DHTML, JavaScript and XML can't handle, you sometimes need so-called "rich" client components for your Web applications. Traditionally, this is the realm of Java (applets) or ActiveX controls.

If your clients are using Internet Explorer 5.5 or higher you have another choice: write your client components in .NET and host them in Internet Explorer. This is an interesting and viable choice if the rest of your development work is also in .NET, since you can use a single technology and a single framework for all your needs, both on the client and the server. This is a good thing, since reducing the number of different technologies reduces some of the development risks and associated costs.

Writing .NET components to run on the client is called IE Sourcing. It's not very well documented, and there are a lot of traps and pitfalls if your component does non-trivial things. This article will use a simple example to show you how to write and deploy a .NET client component and how to deal with the various issues that crop up during development.

Prerequisites for Development
To use the techniques described here, you need Visual Studio 2005 Service Pack 1 (SP1) since that supports "Web application projects." Web application projects is a fully supported extension for Visual Studio 2005 and its build semantics allow customizable build actions. As you'll see, this is something we badly need for what we want to do, and that isn't available in the default Web site projects that shipped with Visual Studio 2005.

If for some reason you can't install SP1, you can download the "Visual Studio 2005 Web Application Projects" as a separate extension at http://msdn.microsoft.com/asp.net/reference/infrastructure/wap/default.aspx (be sure to download and install the VS80-KB915364-X86-ENU.exe update first, which is documented there).

Conventions
When I talk about a command prompt, I mean the Visual Studio 2005 command prompt, with the correct environment settings for x86 tools. I often illustrate techniques using code snippets: they are compact "highlights" of C# code illustrating key points with any useless overhead removed. To see the actual working code in context, consult the accompanying source code files, which can be downloaded from the online version of this article at http://dotnet.sys-con.com.

A Simple Client Control
Client controls derive directly or indirectly from System.Windows.Forms.Control. To get started, we'll develop a control that does nothing more than show one of my favorite URLs and the base directory from where the control was loaded, centered on the control's client area. The implementation, shown in Listing 1, is extremely simple.

As simple as it is, there are two things noteworthy about that code:

• Unless you have some special initialization to do, there's no need to define a constructor. If you do need a constructor, don't specify any parameters since IE will only call the parameter-less constructor.
• Note the absence of any default width and height values of the control. This is intentional; we want the size to be determined when we actually use the control on a Web page. If you want a control to have a certain default size, override the DefaultSize property.

Hosting in a Windows Form
Since it derives from System.Windows.Forms.Control, it can be used in a plain Windows application. I know this article is about hosting in Internet Explorer, but I nevertheless recommend that you debug your component first by embedding it in a plain Windows form.

It's not a perfect debugging environment (since it doesn't mimic all the settings Internet Explorer uses as the Common Language Runtime (CLR) host) but it's good enough for smoke testing.

The following code is the simplest Windows form code hosting our control. As you can see, it's all in the form's constructor:

using System;
using System.Windows.Forms;

using ClientComponent;

namespace ClientComponentTest
{
   public partial class Form1 : Form
   {
     public Form1()
     {
       InitializeComponent();
       MyComponent myComponent = new
         MyComponent();
       myComponent.Dock = DockStyle.Fill;
       SetStyle(ControlStyles.ResizeRedraw,
         true);
       Controls.Add(myComponent);
     }
   }
}

You just need to remember to reference the ClientComponent.dll assembly in your application. The lines...

myComponent.Dock = DockStyle.Fill;
SetStyle(ControlStyles.ResizeRedraw, true);

...make sure that the size of our control follows the size of the form, and is redrawn each time our form changes size.

Lo and behold, Figure 1 shows what we get when running ClientComponentTest.exe.

The base directory d:\Source\article\IESourcing\ClientComponentTest\bin\Debug\ happens to be the path from where the ClientComponent.dll was loaded. So far so good.