managed and unmanaged code in the same process

jens__

Hi,

Is it possible to use Ice to wrap unmanaged code (native C++) so that managed code (.Net C#) can directly call the unmanaged code, without the client-server model described in your tutorials? In our case, some of the managed and unmanaged code has to be executed in the same process. Do you see a way to use Ice for this purpose?

Thanks a lot!

-- Jens

michi

I'm not sure whether this question has anything to do with Ice. If you want to call from C# into C or C++ directly, you can do so by using P/Invoke. (Ice does this for bzip compression. You can find the code for this in BasicStream.cs--look for MANAGED.)

So, I'm not sure whether your question really applies to Ice. If you mean "can Ice C# client code call Ice C++ server code that lives in a DLL that is linked with the client?", I suspect the answer is "yes, but it's awkward." (I admit I have not tried doing this...)

You would put the server into a DLL, with an entry point that initializes the server (creates the communicator, object adapter, etc). The C# code would use P/Invoke to call that entry point to get the server initialized, and then could use normal C# client-side calls to invoke operations. The server would use loopback for its object adapter endpoint.

But I don't really see the point of doing this: it would be simpler to run the server as a separate process on the same machine. Also note that any code that uses P/Invoke isn't verifiable and therefore not CLS compliant, so you cannot, for example, have it execute inside a browser.

Cheers,

Michi.

jens__

Hi Michi,

I agree that it would be much simpler to run the server as a separate process on the same machine. Unfortunately, starting a separate process is not always possible in our case. So, my question was if it is possible to use (or misuse) the slice files to automatically generate code for a C# adapter (that in turn uses P/Invoke) and code for native c++ library skeletons that are called by the adapter. In principle it’s similar to what you do with Ice, just the generated code is different.

So, why do we want to do this? We plan to use Ice as communication platform and it would be nice to use the same concepts to make legacy code directly accessible...

Cheers,
Jens

michi

jens__ wrote: »

So, my question was if it is possible to use (or misuse) the slice files to automatically generate code for a C# adapter (that in turn uses P/Invoke) and code for native c++ library skeletons that are called by the adapter. In principle it’s similar to what you do with Ice, just the generated code is different.

I suspect this would be possible, but definitely not trivial, especially when considering the arcane black magic require for P/Invoke...

My best suggestion is to see whether you can make it work in principle, as I outlined in my previous post, and then look at the specific operations and signatures used by your application, to see whether a code generation approach would be feasible. You could use slice2cs a starting point for inspiration. However, I have to warn you that the mapping internals and entry points in the Slice namespace are not part of the Ice public API, so your approach may turn out to be fragile in the long term because we need the freedom to change the entry points as we develop Ice.

Cheers,

Michi