Martin Kretzschmar wrote:
The climaker uses UNO to obtain the type information. It does not read the registry files directly, it rather uses a "type description provider" service which offers a kind of reflection API.Hi Joachim,
Thanks for the quick reply.
Am Mittwoch, den 09.02.2005, 14:53 +0100 schrieb Joachim Lingner:
If I read the code correctly, a pure C# version of UNO-CLI is not possible, because the bridge has to have C linkage.
The binary UNO interface is defined in C. That means, that a CLI runtime must be accessable through a C interface. For example, the Java bridge uses the Java Native Interface.
Okay, that is what I thought.
If you'd rewrite UNO-CLI as portable as possible, where would you make the managed/native split? (I'm just trying to have you do my homework ;-)
The CLI-UNO bridge depends on the capability of the C++ compiler to produced mixed code. That is, the library contains native code and managed code. This cannot be simply devided.
As far as I know, Mono does not provide such a C++ compiler.
That is unfortunately correct.
So you need to look for a way to make C code speak to CLI code and vice versa. If you have sorted this out you should have a close look at the Java bridge, to get an understanding of how the bridge works.
Thanks for the pointer. I'll look at the Java bridge.
It is difficult to understand how the bridges work. So you could spend quite some time over it. However, if you are serious the Java JNI bridge is a good starting point.
I was surprised to find quite a bit of documentation for bridges and even bridge writing in the Developer's Guide and on udk.openoffice.org. I'm working through that.
You must also take into account that you need to provide the UNO types as CLI types. We have a tool called climaker which does this (project cli_ure). climaker is also written in managed C++ code and uses extensively the System.Reflection.Emit classes. It is used to create assemblies containing all the UNO interfaces, Enums, etc.
climaker uses the C++ UNO binding to use UNO reflection, read the
registry files, etc, is this correct?
With a working CLI UNO binding
Yes. You need however a bit of glue code. the mono cli_maker would be a C# executable. At program start it needs to bootstrap UNO, because it needs the type description provider server. This is achieved by calling into a native (C++) library, where UNO is bootstrapped. The C# function+runtime environment, is it possible to rewrite climaker purely managed (e.g. in C#)?
would return a component context which can be further used to created the needed UNO services. For example in MS C# you could have something like:
[DllImport("CLI_UNO_Bootstrap.DLL", EntryPoint="getContext",
CallingConvention=CallingConvention.StdCall)]
public extern XComponentContext getContext( );Seeing this I get first doubts, because you have a hen and egg problem here. The UNO interfaces which you need to get the UNO type information must be created first, for which the climaker is used :(
But you could use the mono runtime from a C++ program and use its C/C++ interface to use the emit framework. But you have to clarify first if such an interface exists at all. For MS there is only the cumbersume Automation interface (IDispatch).
If we however assume that mono IL code is compatible to MS IL code and the libraries have the same binary format (which could be but must not) then one could use the windows climaker to create the types assembly and just put the library into the Linux OO distribution.
Well that is quite an undertaking. Do not underestimate the work. Anyway, good luck with that.
Joachim
Regards,
Martin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
