OpenOffice-based applications with Mono and MonoDevelop

The entire OpenOffice suite is built on top of a component technology called UNO (which is inspired by COM, but heavily extended). Pretty much all of the functionality in OpenOffice is exposed through some UNO interface, and although the native interface is built on top of C++ many bridges have been created over the years that expose UNO to a variety of languages, runtimes and object brokers.

A few years ago, Sun implemented a .NET bridge for UNO. This bridge allowed .NET developers to script, extend and reuse open office as a library from C# or any other .NET language.

A couple of years ago, Michael Meeks and the OpenOffice community ported the bridge to work with Mono which allows developers to create OpenOffice based solutions using any of the Mono programming languages (C#, Boo, IronPython, IronRuby, F#, VB, Nemerle and so on).

But even if the engine existed, it was not properly installed in the system and getting a C#-based OpenOffice solution required lots of Unix skills, the kind of skills that would likely be in short supply by those interested in OpenOffice automation. We fixed this in this last development cycle, so now a Novell OpenOffice installation will have everything you need.

Michael Hutchinson, one of our MonoDevelop hackers has put together the missing pieces to simplify the process. He has created the solution templates necessary to create these solutions, and packaged them as a Mono.Addin for exiting MonoDevelop users.

To build OpenOffice solutions, you need to install the OpenOffice addin for MonoDevelop. To do this, follow these steps.

Activate the Add-in Manager

Select Templates.

Select the OpenOffice Automation Samples

Complete the installation for the Mono.Addin, once you are done, create a new Solution:

You can skip this step, and get back here later, but you might want to select "Unix integration":

Take advantage of code-completion:

This is what the default sample looks like, you can use this as a foundation for your program. Since this is a COM-based API, it is not an API that is easy to discover with code-completion popups, so we figured it was best to ship full working samples:

Build and run your application by hitting F5:

Your OpenOffice solution in all of its glory, this is from the samples that we distribute as part of the templates:

Improving the OOo API

Sadly, the OOo API exposed by UNO does not look or feel very .NET-ish at all. It is a COM-based API and is not very discoverable. Code-completion will sadly not be of much help without the samples.

Additionally, the conventions used in the code are not very .NETish, so it will feel a little bit odd.

There are a few options here, we could either massage the .NET exposed API into something more .NET-friendly, or we could create a wrapper around the UNO API for most common usage scenarios. We are not sure what would be best.

We believe using a Cecil-based tool-massager we could rewrite the cli_types.dll library to get a more .NET-ish API:

• Rename classes and methods to follow the casing conventions for .NET.
• Turn setters and getters into properties.
• Change the XBlah convention into IBlah convention for interfaces.

This still leaves the issue of interface identity to be solved where an underlying object that always implements IA, IB and IC interfaces is usually only exposed as one of those interfaces, and you must do an explicit cast to the other interfaces to access the other features.

Thanks to the Michaels for all the hard work.