0

I am trying to develop a RTD server similiar to this example in C#.
The RTD server requires another .NET dll which uses a native C-dll. The .NET dll calls the native C dll via Interop.
So far I have copied both DLLs into the same directory as the .exe file. How should I deploy them so that they can be used from the COM server?
The calls to the native library currently look like this

[DLLImport("xxx.dll", EntryPoint="yyy, CallingConvention=CallingConvention.Winapi]
private static extern yyy(ref zzz arg);
Community
  • 1
  • 1
weismat
  • 6,743
  • 3
  • 38
  • 55
  • 1
    Is the RTD Server an out-of-process COM server? (You say 'same directory as the .exe file' - which .exe file?) – Govert Mar 13 '12 at 08:00
  • An RTD server is a Component Object Model (COM) Automation server that implements the IRtdServer interface. I guess I just need to a path or install the dll in %PATH% - have not thought about this before. – weismat Mar 13 '12 at 08:18
  • 1
    Are you calling the native C .dll via P/Invoke (with Declare attributes in your code)? If so, one approach to make the P/Invoke calls work is to explicitly load the C .dll into the process via LoadLibrary, before any of the other calls to it are made. With the LoadLibrary call you can explicitly give the path to the .dll. – Govert Mar 13 '12 at 08:50
  • Currently I am using DLLImport statements together with the extern keyword. – weismat Mar 13 '12 at 08:59
  • 1
    Yes, that's equivalent to Declare (which is used in VB). Have a look here: http://stackoverflow.com/questions/530143/can-net-pinvoke-dynamically-load-a-native-dll-from-a-user-specified-directory – Govert Mar 13 '12 at 09:12
  • I guess I need to ensure that it is called before the first function is called - for RTD there is fortunately a clear entry point (Server start), but will this work for different DLLs as well as I have DLL1 RTD server calling DLL2 calling the C-function? – weismat Mar 13 '12 at 13:04
  • 1
    Yes - if the .dll is already loaded into the process (using LoadLibrary) then any subsequent calls via P/Invoke (DLLImport) will succeed, because the .dll probing will find that it is already loaded - it doesn't matter how it got loaded. This won't work for managed (.NET) assemblies though - .NET assembly loading works totally differently. With Excel-DNA I set the AppDomain's ApplicationBase explicitly, so that managed assemblies in the same directory as the add-in are found by the .NET loader. You might try the deprecated SetPrivateBinPath call, but I haven't tried it recently. – Govert Mar 13 '12 at 15:33

0 Answers0