Problems deploying C++ dll that references C# dll - page 2

New comment
 
clam61:

Anyone with a COM interop example, of calling a managed C# dll from unmanaged C++?

With a .NET assembly which is simply marked as COM-visible, I do something like the following:

// Import the .tlb file created by the .NET compiler, and use its namespace
#import "c:\MyDotNetProject\Whatever.tlb"
using namespace Whatever;


extern "C" void WINAPI MyFunction(...)
{
   // Initialize COM
   CoInitialize(NULL);

   // The _WhateverPtr class is created by the #import directive
   _WhateverPtr pObject = NULL;
   
   // Instantiate the object via its ProgId
   if (SUCCEEDED(pObject.CreateInstance("MyProject.MyClass"))) {

       // Use the object (bearing in mind that all string parameters will need 
       // to be converted from MT4's ASCIIZ to BSTRs)
       pObject->FormatHardDisk();
 
   }

   // Free COM resources
   CoUninitialize();

   // etc.
}
 

hi guys,


i did put all DLLs in the metatrader 4 directory. on top of that i added the metatrader 4 directory to the PATH variable. i followed this dot net for MT4 tutorial and it all works on my dev machine

http://www.codeguru.com/csharp/.net/cpp_managed/windowsservices/article.php/c14735

however it does not work on the other machine. this tutorial also does not work on the other machine.


anyways i changed the C# dll to implement the COM interface and it works...partially. i have another problem and i will start a new thread because it might help some others too.

 
jjc:

I'm not sure what "MS-exclusive technology" has to do with it. Compiled code from Linux or OS X cannot be used natively on Windows, and vice versa. The source code can potentially be re-compiled without modification for each platform, or run through some sort of emulator in some scenarios, but that's different. Even if you could use .NET to create DLLs with plain function exports, you still couldn't take the compiled DLL file and transport it for immediate use on a non-Microsoft platform. I don't see how this in itself materially adds to Microsoft lock-in.

The more immediate issue appears to be that MetaQuotes have created a new proprietary language for a Windows-only application (MQL5), but this language still doesn't have COM support, let alone .NET support. Despite the fact that COM is now seventeen years old. There are very good reasons why MetaQuotes have done this - and, on the whole, I prefer it this way - but it's not Microsoft's fault that you cannot call COM libraries or .NET libraries directly from MQL4/5 code.

You "CAN" call .Net libraries from MQL4, I do it regularily. No wrappers or anything just the .Net Assembly, it requires a trick or two to expose the methods.

If anyone is interested I have a Custom Template for Visual Studio 2008 and a custom ToMT4.exe that enables the programmer to program in Vusual Studio in c# or in fact any .Net languge and compile as normal. It produces the .def file and an altered assembly. All that remains is to copy the assembly and the .def file to MetaTrader make an mqh file and it works.

 
Guiri:

the .def file to MetaTrader
MetaTrader does not use the .def files. The def files are needed by the compiler/linker when creating the dll. They are not for deployment.
 
jjc:

With a .NET assembly which is simply marked as COM-visible, I do something like the following:


In order to create .NET objects in MT4 code, you would need to host the .NET mscoree.dll in first place. However, a much simpler approach might be using a MT4 / .NET bridge. Have a look at: http://www.algoinvest.net/2011/06/metatrader-4-programming-in-net-c_25.html

 

A basic check, in your dev environment are you using debug mode and release mode for your distributables? If yes, try testing in release mode on your dev box.

12
New comment