Dear Code Camp Audience

Dear Audience of my Dayton-Cincinnati Code Camp Presentation,

I just realized that I started to explain something, promised that I would touch on it later, but then completely forgot. What can I say? The day was long, the hardware was not working, and everybody just wanted to play with the Xbox anyways...

Do you remember that object tag in the HTML that contained my Solitaire control? It looked something like this:

<object
classid="http:SolitaireMCE.dll#SolitaireMCE.SolitaireUserControl"
height="100%"
width="100%" />

Well, that's how you would use a .NET Winforms Control as an applet within HTML, very similar to how you use ActiveX controls. But, because this is pure .NET, you have to be mindful of Code Access Security. The biggest implication is that you cannot use a "file:" protocol to point to the assembly, so that leaves web servers as the only delivery mechanism (so that the source can be verified).

But, you can add some COM Interop attributes to your code, and actually transform your Winforms control into a ActiveX control (as far as Windows is concerned). This is what I did not demo to the group.

Why would you want to do this? For starters, once an ActiveX control is downloaded, it's cached differently than .NET assemblies. The classid attribute contains just a GUID instead of naming a DLL and the object within the DLL. This means that Windows won't try to fetch the DLL from the web server each time the page loads if that GUID has already been registered in the Registry.

And this has great implications for installation of your Media Center Hosted HTML Application: your installation program can do the steps to register the ActiveX version of your Winforms control on the destination MCPC, and then you will not need a web server because the Registry entry for the object's GUID will be pointing to a local copy of the DLL.

Love,

Jason


(ok, so I blatently stole the idea to write in the form of a letter from Rory)