Writing a simple managed control under IE
Most web developers are aware of various "controls" and "applets" that can be "hosted" by "Internet Explorer" (hmm, not sure why I quoted that last thing, I guess I was on a "roll".) This code is compiled code that runs within the IE process and draws itself within the boundaries of the document. The control even has access to the outside container. This is useful for doing all sorts of nifty stuff that might be hard to do using pure script or HTML, such as drawing graphs, animation, creating an interactive grid, creating a chat room, etc. Most of these controls are written in Java or COM (ActiveX). Java requires a special runtime that you have to download, and ActiveX requires your users to be running one of the many ActiveX compatible web browsers (There's tons! IE3.. Umm, IE4.. IE5.. Oh yea, IE5.5.. IE6, just to name a few).. However, what if you really want to keep users away from your site and write a control that requires them to download a special runtime ANNNNND only be able to use one browser. Well, then my friend you definitely need to write your own managed controls.
Only a hand full of web developers are aware that IE (recent versions, not sure which ones) can run managed code. Even less than a hand full (maybe a paw of a very small cat?) can actually tell you how to do this. Provided your users have the .NET framework installed (who doesn't?) there's a special syntax of the <object> tag that can instantiate a managed Winforms control. I found information on the Internet a little sparse on this subject so I decided to write a post describing exactly how to do this. Not that you should, as I'm sure I'll get 32,768 comments telling me that my apps are crap, proprietary and how that mentality somehow mirrors the exact attitude of Microsoft as a whole. Well, let me tell you something. This blog is dedicated to building web based applications, not web pages. Applications run on a certain platform. That platform might be Windows, that platform might be Mac, that platform might be the Java runtime. It might be a Commodore PET, a cell phone, a Zune, one of those old TI-85 graphing calculators, whatever. This platform can also be Internet Explorer. In fact, one of the reasons IE became so much more popular (especially within corporate networks) over say, Netscape, is it's an actual web application platform - not just a browser. Authors of applications can write applications for whatever platform they choose, based on its requirements as well as the users of said application. I might write an IE specific application for setting up direct deposit because my IT department has rolled out IE to everyone in my company. It's cost effective to target a single platform. There exists a certain spectrum; on one side you can scale to many different types of users but your development/test costs go way up and/or your feature set goes way down. On the other side, you can write a program once for a certain platform and target a very specific set of users. It's up to developers to figure out the best spot in that spectrum for their specific application. So enough of my rant, let's get back to the subject.
First, let's create a managed DLL with a single class in it. Since I don't feel like writing a full fledged control, all this thing will do is pop up a message box. Or maybe I don't actually know how to program and this whole blog's a lie. However, you'll get the point - you can add more controls to the child controls collection, override all sorts of events, etc.
[assembly:System.Security.AllowPartiallyTrustedCallersAttribute]
namespace HostedControlTest {
public class TestControl : Control
{
public TestControl()
{
MessageBox.Show("Hello World!");
}
}
}
Compile the DLL, upload it to your web server in a location that clients have access to reach. You can test this by typing in the URL for the DLL and make sure the IE "Save" dialog comes up and you can download your own DLL. You might have certain web server security restrictions (especially if it's a Sharepoint server) that prevent users from downloading DLL files. It doesn't matter what web server you're using, it doesn't matter if the web server knows anything about .NET. It's simply a binary file sitting up on a server somewhere and it's downloaded exactly how, say, a JPG file is downloaded. Also, I'm pretty sure you can even use another extension other than DLL.
Once you have this working, create a new web page. On the page, place an object tag that looks something like:
<OBJECT classid="HostedControlTest.dll#HostedControlTest.TestControl">
You can replace HostedControlTest.dll with any valid relative path to your DLL. After the pound sign (or, octothorpe as I like to say) is the class within the DLL to load. Note I fully qualify the path with the namespace as well.
Load up your page through your web browser and the control should run and you should get a popup on your screen. No need to sign anything, no need to click "Yes" to any security warnings, etc. In fact, all security is taken care of for you by Code Access Security and is enforced by the runtime's security policy on your machine. Your control can request permissions (such as local file access) and it's up to the client's machine what it trusts the control to do. If a control all of a sudden tries to do something evil, the runtime will throw an exception.
That's all there is to it. Don't ask me any questions because this is all I know! Seriously. Actually, feel free to ask me questions and I'm sure I can find out the answers for you. Thanks!
Mike (Web Dev Guy)
