I wasn’t the first. Shaver (from Mozilla) had this idea as well and started a bit on it. I’m talking about XPCOM. I’ve done enough work to say that I’m working on it. I’ve taken Shaver’s orginial code, got it to work in Windows as well, extented it, re-did the makefiles, changed the coding conventions (sorry Shaver) and documented some of the code.

Anyone that doesn’t know, XPCOM is a product of the Mozilla project. All of Mozilla/Firefox is based on it so its crossplatform. Its very similar to COM in Windows. Making XPCOM work with Mono/.NET gives us access to many of the features in Mozilla natively and eventually to even write components that are expossable back into XPCOM. Not only does it give us access to Mozilla but XPCOM is capable of being self hosted so its possible to use it for its other benifits, such writting componets in Perl, Python, Javascript, Java, C and C++ and interop with them at a native object level (like writing a component in VB6 and consuming it in VB.NET with MS’s COM).

How does it work? Well XPCOM supports a method descriptor system, a sort of reflection, that tells you about a object dynamicly. We get this information at runtime when creating a new object and we create a virtual class object version of that using Reflection.Emit, that represents the object in XPCOM.

To access something in XPCOM, its very similar to way you can call the Activator object and create a new instance of a com object and it will run the com wrapping system for you. Also, in MS .NET, there is a tool called “tlbexp.exe” that creates a physical assembly for the COM wrapper, so you don’t have to call the methods on the COM object via reflection and you can build directly against something. I’m currently working on a facility to do this same exact concept with XPCOM and have a simiple tool wrapper that writes the assembly to file.

I’m also working on how we can expose back into XPCOM from Mono using a combination of the Mono embedding api and custom attributes to wire and map everything up.

Some aspects are pretty hard. There were a lot of design concepts I could of really used, however I felt it was best to mimic the way COM works with .NET in Windows.

Don’t get confused. XPCOM is not COM nor a drop in replacement. COM objects that run in Windows don’t work magicly under XPCOM. Its very very different in many ways and very very similar in others. However from the Mono/.NET, its not going to be much different to get used to from COM.

More info later!!!