Problems deploying C++ dll that references C# dll

Only a suggestion; c and c++ was a bell labs invention, MS developed c# - The combination of the two may not always work as expected on on configurations.

I Hope this is becomming less and less true. As a high level language ( both c++ & C#) they get compiled into object code specific for your machine.

You *May* have a setting which is different.

You should have (or get) a hex editor or do a binary comparison of the compiled code which works against the code which fails.

File-Compare also works

ps I learned to code in the early '70's when all code was hand built in assbly- I understand that things (may) have changed a little, but

the reason for this post is to say- get out some low level tools and continue to test.

* note K & R were at Bell Labs, I forgot where c++ came from.

C++ is compiled to native machine code while C# is like Java, will be compiled to machine-independent bytecode and can only be executed by a virtual machine.

C, C++, Ada, Pascal, Fortran and all the other Systems programming languages which compile to native machine code can simply load and call each other's modules without any troubles, but this interface does not exist for Java or C#. .NET code cannot just be loaded like an ordinary module. Their DLLs do not contain executable code, the name DLL is completely misleading and leads to wrong expectations since they simply ARE NO DLLs. They are more like Java .jar or .class files, they cannot be loaded by the OS, they must be loaded and executed by the VM.

They intentionally named their bytecode files .EXE and .DLL to make it look like such to an ordinary user, while they really should name them .net or .nar or something (I would vote for the latter: .jar for Java and .nar for .NET, this would generate the correct associations in the users' minds). Unfortunately it seems they really have success with this tactics: People really start believing they could create EXE and DLL with these compilers.

There exists a way to compile and install them as COM objects somehow but this requires an installer on the target machine which will register the objects in the windows registry but there is no way to create a DLL with .NET. This is the price one pays for using this proprietary incompatible stuff.

Not quite the whole picture. Both Java and the .NET languages generate bytecode, but this is then JIT-compiled to native code. The .NET languages do not generate bytecode in the sense of something which is then run through an interpreter (as was the case with e.g. Visual Basic 3 many, many years ago). Overheads associated with JIT-compilation of .NET code can be alleviated using NGen.

You also need to check that the installer is creating the registry entries which are required for COM. I don't know if this happens automatically when a COM-visible assembly is installed in the GAC, or whether it's an additional step which the installer has to carry out itself. (I have successfully used Wise for this kind of installation, but I don't know whether Wise is creating the registry entries, or whether it's automatic).

(And, just in case: whichever installer you are using needs to be able to do proper GAC installation. A simple file copy into the GAC directory doesn't work.)

EDIT: I've just checked an old installer of mine, and it turns out that I manually added the necessary registry keys to the installation. You can read more about this kind of deployment at http://www.simple-talk.com/dotnet/visual-studio/build-and-deploy-a-.net-com-assembly/, which seems to imply that COM-visible assemblies do not have to be installed in the GAC.

My point was emphasizing that these assemblies are not pure machine code from the beginning on that can simply be loaded and then provide callable function exports like any other DLL. Whether the VM is later doing its things with jit or not is only an implementation detail, it does not make these assemblies more or less interoperable, it only impacts performance.

They [Microsoft] could have made things so much easier if their compiler would automatically generate a loader and for each .NET export a C++ compatible wrapper function to make these DLLs *real* DLLs. I bet they intentionally didn't want this because it would mean more compatibility and compatibility with any non MS-exclusive technology is absolutely contrary to their business model.

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.

I see COM as a MS-Only technology, just like .NET is. Of course compiled code cannot directly run on another platform but with normal compilers I can easily compile the same library as DLL on windows or as a .so on *ix and to whatever it is called on OSX and the function exports work the same way. Everything that uses COM to communicate with its modules cannot be ported anymore to anywhere else without major pain or a complete rewrite. Therefore COM is a MS-Only technology.

Applications that try to be portable will avoid using COM at all costs. If .NET could produce regular DLLs then these DLLs could be used by these portable applications and the same c# library could then also be easily ported to mono and compiled to .so files on the target platform.

The very moment you start using COM (or are forced to use it) there is no chance to ever port it to anywhere else anymore. If this is not vendor lock-in what else would you consider as such?

Currently my C# dll does not implement the COM interface, but magically it works on my dev machine.

On deployment it fails.

I know the COM approach works (I did it once long ago), but I am COMPLETELY ignorant of this stuff.

I found a demo on the MSDN website, but surprise surprise the example wont even compile.

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

I just need to know how to instantiate a C# object and call one function from C++

try copy All your DLL files in MT's main directory, maybe all OK