www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Registration-free COM client

reply Thalamus <f f.com> writes:
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!
Jun 27 2016
next sibling parent reply thedeemon <dlang thedeemon.com> writes:
On Monday, 27 June 2016 at 21:17:52 UTC, Thalamus wrote:
 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?
To load load a COM object from a given file (DLL or AX) without having it registered, just load the file with CoLoadLibrary() and use its DllGetClassObject() function to get IClassFactory which will give you any kind of object in this library. Here's how I do it (in my case the requested object has "IBaseFilter" COM interface): IBaseFilter createDSFilterFromFile(GUID guid, string dir, string fname) { auto curdir = getcwd(); scope(exit) chdir(curdir); chdir(dir); // in case the lib depends on other dlls nearby auto hinst = CoLoadLibrary( cast(wchar*) buildPath(dir, fname).toUTF16z, TRUE); enforce!COMException(hinst); auto fnGetClassObject = cast(LPFNGETCLASSOBJECT) GetProcAddress(hinst, "DllGetClassObject"); enforce!COMException(fnGetClassObject); IClassFactory factory; auto iid = IID_IClassFactory; fnGetClassObject(&guid, &iid, cast(void**)&factory).checkHR("fnGetClassObject failed"); enforce!COMException(factory); IBaseFilter ibf; factory.CreateInstance(null, &IID_IBaseFilter, cast(void**)&ibf).checkHR("factory.CreateInstance"); return ibf; }
Jun 27 2016
parent reply Thalamus <f f.com> writes:
On Tuesday, 28 June 2016 at 02:30:56 UTC, thedeemon wrote:
 To load load a COM object from a given file (DLL or AX) without 
 having it registered, just load the file with CoLoadLibrary() 
 and use its DllGetClassObject() function to get IClassFactory 
 which will give you any kind of object in this library.
 Here's how I do it (in my case the requested object has 
 "IBaseFilter" COM interface):
Thanks to both of you! I was hoping there would be a code-only solution, and I'm glad to see one is possible. It isn't quite working for me yet, though. I can get the HINSTANCE in the CoLoadLibrary call, but GetProcAddress for DllGetClassObject fails, with ERROR_PROC_NOT_FOUND. I've never written a COM server before (only clients), so I must be building the C# assembly incorrectly. I'm just not sure how. Everything across the board is built as 64-bit, and I've selected "Register for COM interop". The C# is pretty simple: [ComVisible(true)] [Guid("B99B6E64-966C-4655-B633-D0108F4DE909")] public interface ITestInterface { int Identifier(); } [ComVisible(true)] [Guid("0F8BDA67-D6CF-42D0-A62D-E19BD7864362")] [ClassInterface(ClassInterfaceType.None)] public class TestClass : ITestInterface { public int Identifier() { return 42; } } and the D code (mostly unchanged from your example): interface ITestInterface { int Identifier(); } ITestInterface GetInstance() { import std.exception; import core.sys.windows.com; GUID iid = { 0xB99B6E64, 0x966C, 0x4655, [0xB6, 0x33, 0xD0, 0x10, 0x8F, 0x4D, 0xE9, 0x09]}; GUID clsid = { 0x0F8BDA67, 0xD6CF, 0x42D0, [0xA6, 0x2D, 0xE1, 0x9B, 0xD7, 0x86, 0x43, 0x62]}; HINSTANCE hinst = CoLoadLibrary(cast(wchar*)r"managed\bin\test.dll".toUTF16z, 0); //CoFreeLibrary will need to be called later. enforce!COMException(hinst); LPFNGETCLASSOBJECT fnGetClassObject = cast(LPFNGETCLASSOBJECT)GetProcAddress(hinst, "DllGetClassObject"); enforce!COMException(fnGetClassObject); IClassFactory factory; auto factory_iid = IID_IClassFactory; fnGetClassObject(&clsid, &factory_iid, cast(void**)&factory).checkHR("fnGetClassObject failed"); enforce!COMException(factory); ITestInterface instance; factory.CreateInstance(null, &iid, cast(void**)&instance).checkHR("factory.CreateInstance"); return instance; } Any ideas what I'm missing? thanks! Gene
Jun 29 2016
next sibling parent reply John <johnch_atms hotmail.com> writes:
On Wednesday, 29 June 2016 at 14:51:10 UTC, Thalamus wrote:
 and the D code (mostly unchanged from your example):

 interface ITestInterface
 {
     int Identifier();
 }
ITestInterface needs to derive from IUnknown.
Jun 29 2016
parent John <johnch_atms hotmail.com> writes:
On Wednesday, 29 June 2016 at 17:55:27 UTC, John wrote:
 On Wednesday, 29 June 2016 at 14:51:10 UTC, Thalamus wrote:
 and the D code (mostly unchanged from your example):

 interface ITestInterface
 {
     int Identifier();
 }
ITestInterface needs to derive from IUnknown.
I realise that doesn't address your question, but the other thing is I'm pretty sure C# will transform the ITestInterface definition into something more like this: interface ITextInterface : IUnknown { HRESULT Identifier(int* result); } And when it comes to calling it: int result; checkHR(instance.Indentifier(&result));
Jun 29 2016
prev sibling parent reply John <johnch_atms hotmail.com> writes:
On Wednesday, 29 June 2016 at 14:51:10 UTC, Thalamus wrote:
 I was hoping there would be a code-only solution, and I'm glad 
 to see one is possible. It isn't quite working for me yet, 
 though. I can get the HINSTANCE in the CoLoadLibrary call, but 
 GetProcAddress for DllGetClassObject fails, with 
 ERROR_PROC_NOT_FOUND.

 I've never written a COM server before (only clients), so I 
 must be building the C# assembly incorrectly. I'm just not sure 
 how. Everything across the board is built as 64-bit, and I've 
 selected "Register for COM interop". The C# is pretty simple:
A little research reveals that C# COM servers don't export DllGetClassObject, or any of the COM server plumbing. "Registering for COM interop" merely adds the registry entries - which is the step you're trying to avoid by loading the DLL dynamically. Then you'd run regasm on it to generate a type library. https://msdn.microsoft.com/en-us/library/aa645738(v=vs.71).aspx
Jun 29 2016
parent Thalamus <f f.com> writes:
On Wednesday, 29 June 2016 at 19:21:50 UTC, John wrote:
 On Wednesday, 29 June 2016 at 14:51:10 UTC, Thalamus wrote:
 [...]
A little research reveals that C# COM servers don't export DllGetClassObject, or any of the COM server plumbing. "Registering for COM interop" merely adds the registry entries - which is the step you're trying to avoid by loading the DLL dynamically. Then you'd run regasm on it to generate a type library. https://msdn.microsoft.com/en-us/library/aa645738(v=vs.71).aspx
Thanks John! Yes, I did forget to add : IUnknown. I would have caught that, but I appreciate you pointing that out. Thanks also for the link to the regasm article.
Jun 29 2016
prev sibling parent John <johnch_atms hotmail.com> writes:
On Monday, 27 June 2016 at 21:17:52 UTC, Thalamus wrote:
 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?
You just deploy the manifest in the same folder as your client.
Jun 28 2016