MozNET Tutorial - Managed Code XPCOM Component

This isn't so much as a tutorial but, a simple walk-through to get you up and running using the generic component templates.
First off I'll give you a run-down of how managed components work with MozNET.

Managed components must implement an interface, defined in the Se7enSoft.MZXPCom.dll assembly, which allows XPCom to create an instance of your class. This interface is fairly simple and straight-forward to implement but, to make everything (a lot) simpler I've created two template items that lays out all the boilerplate code and creates a very generic, yet working, component. The templates come in both C# and VB (no, I didn't forget about you VB guys!).

If you use Visual Studio 2010 (any flavor) you can simply install the templates via an easy to use vsix installer packagethat I quickly whipped up using a freely available addon.

Once you have your templates, installed via the vsix installer, you can start building your own components. The templates are fairly well commented so you should be able to figure most everything out easily. When you start getting lost just refer to the javascript tutorial -page 3 is probably where you'll want to start. It should be pretty easy for you to finish up getting everything working by following the tutorial from page 3. If you haven't written a JS component you may want to start with that tutorial first as its a little easier, in my opinion, than the managed code version and the tutorial will hold your hand all the way through.

Before we move on to the next step you should go and put your first component together. Go ahead, I'll wait.

All put together now? Good.
Now we need to get that thing reg'ed with XPCom otherwise the 52.35 hours of tedious labor that you just put into that component is moot.

Let's begin.
The XPcom class contains an event named XPComInitCompleted. By hooking up to that event - BEFORE - you initialize XPCom you'll get notified when the initialization process has, as the name implies, completed. Inside your handler for this event you'll need write a single line of code for each custom component that you want to register.

The GenericComponent class in the example above points to the name of the class used by the generic component item templates that I've provided. You are using one of the templates for your first component, right? If not you must be a friggin' rock-star programmer ;)

Ok. Now that you have your component written and registered and are starting to debug (because you can't debug your component without first registering it) I need to tell you the rules.


Yes. Rules.

Rather simple rules, actually; and there's only a few of them.
Yeah, I could have started off by stating that there were a couple of rules to this but, I thought I'd let you bust your ass for 64.5 hours first. I'm just like that sometimes ;)
Anyway, first off let me state that when putting your component together, and you should remember this already, you implemented an interface named XPComComponentFactory.IComponentInfo. You remember now, don't ya? Good. Well, anyway.. That interface exports a property aptly named "Name".

Your component cannot export the names 'navigator' nor 'external', they are both off limits to external components. If you try to register a component with either of those names the registration factory will explode, bitching about a ComponentRegistrationException so, don't do it. The last rule is that the name that you export cannot contain spaces. Again, you will receive a ComponentRegistrationException and it will explode in your face - don't do it.

Just as a side note, the name you export - should it be made up of multiple words e.g myComponentName - should be pascalCased (if it's a single word it should be lowercase) because that's how Javascript likes things. One last note, once you register a component - that's it, it's registered. There is no going back. You can't "unregister" a component.

A word to the wise:
Components that are exposed to Javascript create a security risk.
Rogue pages could potentially use your component to cause harm to the users system.
Always and I stress ALWAYS check that the URL of the page calling a script that accesses your component should be allowed to do so.
Ultimately, you are responsible for what your component can or can't do and you need to take the precautions required to filter out any possible rogue pages that could use your component against your application or worse - the host system.

Now that all is said and done..
Get out there and create something cool! Use your imagination. I've just given you the key to the lock on Pandora's box. Now, go open it and see what you can find. If the interest is there and people are willing to create them, I may host a component gallery where you can buy, sell and trade managed XPCom components with each other. The possibilities are now nearly endless. This is the feature that MozNET has been waiting for. You can now completely extend not only MozNET but, in essense, XPCom itself.