note: itchy trigger finger deleted this post from June 15, 2010. So… here we go again
It was hackweek here again in Novell, I spent an enjoyable ( but also sometimes frustrating ) couple of days trying to extend support for Mono in Openoffice.org. Recently on IRC there was some interest in using C# to write extensions for Openoffice.org where it became clear that only being able to ‘drive’ Openoffice.org from C# is severely limiting. To provide decent custom functionality you need to be able to get called by Openoffice.org, integrate with the Menus and Toolbars etc. Clearly to write an extension you need to be able to be ‘plugged’ in.. There are many many C# developers ( and potential extension developers ) and
we are just ignoring them. I have to admit I always wanted to play with C#/DotNet/Mono and I even proposed a GSOC task to try and faciliate this 
Unfortunately the project didn’t make the cut but fortunately there is Hackweek yay! So, I spent the last couple of days playing around with Mono and C#, first I wrote a new loader for Mono, this allowed me to use recomp to register some services, next I modified unopkg to accept a Mono component bundled in an extension.
The source code for the extension is available from here
Then I ported the CalcAddins example from the sdk to Mono, the result can be seen below
The source code for the Calc addin can be found here.
For more information see the details and patch
I didn’t have time to write some managed c++ code to load from DotNet, it should only require a small amount of code since the loader is only
a proxy for the managed code Loader implementation ( that was written for this mono component support and can be reused )
nice work. now if only it went mainstream, and also mono was standard in browsers and CLR languages could be used instead of javascript. I hope that was somebody’s hackweek project
Comment by karl prosser — July 8, 2010 @ 2:30 am
interesting and good work. By the way do you have any plans to contribute the complete mono bridge upstream? A modified climaker only doesn’t make sense.
And by the way we had this stuff already implemented when we developed the CLI bridge or better CLI language binding. But because of some other reasons we removed the extension part.
Anyway i like it.
Comment by Juergen Schmidt — July 8, 2010 @ 9:48 am
@Juergen
First thanks for liking it, I enjoyed working on this too
I think the cws monobridge covers the intent to upstream the bridge. And as you can see from the history of the issue it seems this drags on.
As you can see we really do ( and always did ) want to upstream it.
About the climaker, to me this really does seem necessary in order for the mono-bridge to be useful. I have to admit I don’t understand what the reluctance about accepting that part is. For example when I ported the calc addin to mono I needed to generate new types for the XCalcAddins.idl how could I do that without a climaker that runs on linux? I shouldn’t need to go to a windows machine to run the existing climaker in order to use any new types I define. I dunno, maybe the use case wasn’t clear. Anyway, Juergen I hope you can help smooth the path by lending your support to this cws.
Comment by Noel — July 12, 2010 @ 3:14 pm
@Karl
Thanks for your encouraging words, whenever the mono-bridge gets upstreamed ( and that’s planned ) I would be interested in upstreaming the extension support.
Comment by Noel — July 12, 2010 @ 3:17 pm
Did this ever make it upstream?
Comment by Adam Tauno Williams — December 23, 2010 @ 4:42 am
@Adam
unfortunately not in oracle openoffice
Comment by Noel — January 11, 2011 @ 2:19 pm