Hi everyone,

I've succeeded in using D as a client for regular (registered) COM servers in the past, but in this case, I'm building the server as well. I would like to avoid registering it if possible so XCOPY-like deployment remains an option. Can a registration-free COM client be built in D? If so, how can the code be setup to consume the manifest file, or alternately, is there a way to just point D to the correct assembly directly in code?

Some background info:

The project I'm working on requires a high degree of D and C# interop. Getting C# to invoke D via C linkage is simple, but I've encountered a lot of problems the other way around.

Although it's technically possible to get pointers to C# objects such that the same approach could be used, doing so would require large portions of the code to be marked unsafe, the objects to be instantiated as fixed, use of GCHandle.Alloc, etc., which has a high dev learning curve and scalability issues.

The typical solution is to use delegates as callbacks. This works, but it doesn't scale well to more complex scenarios. You can send a struct of delegates to the D layer and use that to access public methods in a class, but if one of those methods would normally return a instance of a different class and the caller will need to invoke methods within that other class, this approach breaks down. For example, MyClassInstance.MyProperty.DoSomething() can't be modeled as MyClassInstanceDelegate.MyPropertyDelegate.DoSomethingDelegate(). This fails marshaling, because delegates are not blittable. There's very likely a way to structure complex delegate hierarchies that would in the end be marshalable, but the implementation and maintenance overhead would be sizable.

This leaves COM, which seems like it would work fine, on Windows anyway. (I'm not sure about Linux, but maybe some combo of Mono and WINE would do it? Not a high prio right now.) I'm hoping, though, to avoid having to register the C# COM server to keep things as simple as possible.

thanks!

Reply via email to