I have a particular function in an Excel addin(xll).
The addin is proprietary and we do not have access to the source code. However we need to call some functions contained within the addin and we would like to call it from a C# program.
Currently, I was thinking of writing a C++ interface calling the Excel function with xlopers, then calling this C++ interface from C#.
Does anybody who has prior experience of this kind of issues know what would be the best solution for that ?
Anthony
You need to create a fake xlcall32.dll, put it in the same directory as your XLL (do not put excel's own xlcall32.dll in the PATH). Here is some code:
# include <windows.h>
typedef void* LPXLOPER;
extern "C" void __declspec(dllexport) XLCallVer ( ) {}
extern "C" int __declspec(dllexport) Excel4 (int xlfn, LPXLOPER operRes, int count,... ) { return 0; }
extern "C" int __declspec(dllexport) Excel4v(int xlfn, LPXLOPER operRes, int count, LPXLOPER far opers[]) {return 0;}
Now suppose I have an XLL called xll-dll.xll with a function called (use "depends.exe" to find out the names of the exported functions) xlAdd that well adds two doubles:
extern "C" __declspec(dllexport) XLOPER * __cdecl xlAdd(XLOPER* pA, XLOPER* pB);
The following code calls it:
# include <windows.h>
# include <iostream>
// your own header that defines XLOPERs
# include <parser/xll/xloper.hpp>
// pointer to function taking 2 XLOPERS
typedef XLOPER * (__cdecl *xl2args) (XLOPER* , XLOPER* ) ;
void test(){
/// get the XLL address
HINSTANCE h = LoadLibrary("xll-dll.xll");
if (h != NULL){
xl2args myfunc;
/// get my xll-dll.xll function address
myfunc = (xl2args) GetProcAddress(h, "xlAdd");
if (!myfunc) { // handle the error
FreeLibrary(h); }
else { /// build some XLOPERS, call the remote function
XLOPER a,b, *c;
a.xltype = 1; a.val.num = 1. ;
b.xltype = 1; b.val.num = 2. ;
c = (*myfunc)(&a,&b);
std::cout << " call of xll " << c->val.num << std::endl; }
FreeLibrary(h); }
}
int main()
{test();}
My exe actually works (to my own surprise), and output 3 as expected. You must have some knowledge of what your XLL actually expects for parameters. If it allocates some memory, you must check if the #define xlbitDLLFree 0x4000
is set on your XLOPER c->type, and call back "xlAutoFree".
You might like to try XLL Plus http://www.planatechsolutions.com/xllplus/default.htm. It's a bit pricey, but the
XLL Wrapper Libraries feature is exactly what you are looking for:
"Sometimes it is useful to be able to call your Excel add-in functions from other environments, such as command-line programs or interactive applications, written in C++, Java, C# or Visual Basic. The Xll Wrapper toolkit contains tools, a runtime library, samples and documentation to help with the development of COM modules and .NET assemblies that wrap Excel XLL add-ins"
An Excell add-in DLL might be written in C#. If so, then you can probably bypass Excel altogether. Might need a wrapper though.
check whether assembly is available in program files where you install the plguin,
reference that assembly directly to your c# project - check the object browser for your class, method or object
You should be able to use reflection to get access to your addin. try using The Reflector to see what's available.
Related
Hy everyone i have a bit of a problem, I program mostly in python, and it's been a while actually since i coded in C# and i code in mql every now and again. My problem is i built a C# dll file that has a couple of simple functions:
[DllExport("debugger", CallingConvention = CallingConvention.StdCall)]
[return: MarshalAs(UnmanagedType.LPWStr)]
public static string debugger()
{
return "Send help!! SOS";
}
[DllExport("debugger2", CallingConvention = CallingConvention.StdCall)]
public static int debugger2()
{
return 12345;
}
This is my simple code from my C# file, it's all inside a public static class and the Solution platform is x64. Code compiles just fine and i find no issues. Now this is how my MetaEditor code looks:
#import "simpleFunctions.dll"
string debugger();
int debugger2();
#import
int OnInit()
{
//Print a statement just to show where code crashes
Print("We are definitly in it :D");
Print(debugger);
}
From what the Journal tells me everything runs just fine, the file is added from libraries and the print statement at the beginning of the OnInit function runs as well. The problem is come when calling the first debugger function from my dll file, just below my Print statement in the journal i get the following errors:
- Cannot find 'debugger', in 'simpleFunctions.dll'
- unresolved import function call
- OnInit critical error
- tester stopped because OnInit failed
I have searched all over the internet to my dissatisfaction of finding that no one really answers this question in a practical way. I suspect the error lies maybe in the C# side of things with regard to data type differences but i really don't know where to continue looking at this point. Any help would be greatly appreciated.
Well after searching probably every website for an answer relating to my question, switching back to python and trying a different way to connect to mql5 (using sockets), than finally trying C++ and spending the last two days learning that, I think I finally solved my problem. Only posting this to help anyone who might have a similar problem in the future. I figured that since MQL5 is more like C++ than C# the linking process would be a bit easier. The code it's self was not complex at all because I was just trying to get functions running in MQL5 from C++.
#include "pch.h"
#include "CPPMQLSQLConnector.h"
#define CPPMQLSQLCONNECTOR_API
#include <string>
std::string __stdcall myString(std::string Words)
{
static std::string myWords = "This is about to work I can feel it. ";
return myWords + Words;
}
int __stdcall myInt(int numbr)
{
static int myNumber = 1998;
numbr = 22;
return myNumber + numbr;
}
Note the __stdcall before method pointer, calling convention is required to let MQL5 know how to get the functions from the library.
In my C++ header file I let C++ know which functions I want to export using the '__declspec(dllexport)' and the '__declspec(dllimport)', my opinion on this issue is worth as much as you paid for it but my understanding is that the export keyword let's C++ know which functions I would like to export and the import keyword is used by MQL5 or which ever application, to know which functions to import. My header file
#pragma once
#include <string>
#ifndef MYDLL
#define MYDLL
#ifdef CPPMQLSQLCONNECTOR_API
extern "C" __declspec(dllexport) std::string __stdcall myString(std::string Words);
extern "C" __declspec(dllexport) int __stdcall myInt(int numbr);
#else
extern "C" __declspec(dllimport) std::string __stdcall myString(std::string Words);
extern "C" __declspec(dllimport) int __stdcall myInt(int numbr);
#endif
#endif
We use the extern "C" keyword to let the compiler know it should expect 'C' code.
Finally the MQL5 code, it's very simple. We just import the dll and and start using the functions for what ever purpose they were made
#import "CPPMQLSQLConnector.dll"
string myString(string s);
int myInt(int i);
#import
int OnInit()
{
string Word = "Momma I made it!!!!!!!!!!!!";
int numbr = 25;
Print("We definitely init ;D");
Print("La string: ", myString(Word));
Print("La integer: ", myInt(numbr));
return(INIT_SUCCEEDED);
}
I have a C lib and want to call function in this library from C# application. I tried creating a C++/CLI wrapper on the C lib by adding the C lib file as linker input and adding the source files as additional dependencies.
Is there any better way to achieve this as am not sure how to add C output to c# application.
My C Code -
__declspec(dllexport) unsigned long ConnectSession(unsigned long handle,
unsigned char * publicKey,
unsigned char publicKeyLen);
My CPP Wrapper -
long MyClass::ConnectSessionWrapper(unsigned long handle,
unsigned char * publicKey,
unsigned char publicKeyLen)
{
return ConnectSession(handle, publicKey, publicKeyLen);
}
The example will be, for Linux:
1) Create a C file, libtest.c with this content:
#include <stdio.h>
void print(const char *message)
{
printf("%s\\n", message);
}
That’s a simple pseudo-wrapper for printf. But represents any C function in the library you want to call. If you have a C++ function don’t forget to put extern C to avoid mangling the name.
2) create the C# file
using System;
using System.Runtime.InteropServices;
public class Tester
{
[DllImport("libtest.so", EntryPoint="print")]
static extern void print(string message);
public static void Main(string[] args)
{
print("Hello World C# => C++");
}
}
3) Unless you have the library libtest.so in a standard library path like “/usr/lib”, you are likely to see a System.DllNotFoundException, to fix this you can move your libtest.so to /usr/lib, or better yet, just add your CWD to the library path: export LD_LIBRARY_PATH=pwd
credits from here
EDIT
For Windows, it's not much different.
Taking an example from here, you only have yo enclose in your *.cpp file your method with extern "C"
Something like
extern "C"
{
//Note: must use __declspec(dllexport) to make (export) methods as 'public'
__declspec(dllexport) void DoSomethingInC(unsigned short int ExampleParam, unsigned char AnotherExampleParam)
{
printf("You called method DoSomethingInC(), You passed in %d and %c\n\r", ExampleParam, AnotherExampleParam);
}
}//End 'extern "C"' to prevent name mangling
then, compile, and in your C# file do
[DllImport("C_DLL_with_Csharp.dll", EntryPoint="DoSomethingInC")]
public static extern void DoSomethingInC(ushort ExampleParam, char AnotherExampleParam);
and then just use it:
using System;
using System.Runtime.InteropServices;
public class Tester
{
[DllImport("C_DLL_with_Csharp.dll", EntryPoint="DoSomethingInC")]
public static extern void DoSomethingInC(ushort ExampleParam, char AnotherExampleParam);
public static void Main(string[] args)
{
ushort var1 = 2;
char var2 = '';
DoSomethingInC(var1, var2);
}
}
UPDATE - Feb 22 2019: Since this answer has been getting quite a few upvotes, I decided to update it with a better way of calling the C method. Previously I had suggested using unsafe code, but the safe and correct way is to use MarshalAs attribute for converting a .NET string to a char*. Also, in VS2017 there is no Win32 project anymore, you'll probably have to create a Visual C++ dll or empty project and modify that. Thank you!
You can directly call C functions from C# by using P/Invoke.
Here's a short how-to on creating a C# lbrary that wraps around a C dll.
Create a new C# Library project (I'll call it "Wrapper")
Add a Win32 project to the solution, set application type to: DLL (I'll call it "CLibrary")
You can remove all the other cpp/h files since we won't need them
Rename the CLibrary.cpp file to CLibrary.c
Add a CLibrary.h header file
Now we need to configure the CLibrary project, right-click it and go to properties, and select Configuration: "All Configurations"
In Configuration Properties > C/C++ > Precompiled headers, set Precompiled Headers to: "Not using Precompiled Headers"
In the same C/C++ branch, go to Advanced, change Compile As to: "Compile as C code (/TC)"
Now in the Linker branch, go to General, and change Output File to: "$(SolutionDir)Wrapper\$(ProjectName).dll", this will copy the built C DLL to the C# project root.
CLibrary.h
__declspec(dllexport) unsigned long ConnectSession(unsigned long handle,
unsigned char * publicKey,
unsigned char publicKeyLen);
CLibrary.c
#include "CLibrary.h"
unsigned long ConnectSession(unsigned long handle,
unsigned char * publicKey,
unsigned char publicKeyLen)
{
return 42;
}
Right-click CLibrary project, build it, so we get the DLL in the C# project directory
Right-click C# Wrapper project, add existing item, add CLibrary.dll
Click on CLibrary.dll, go to the properties pane, set "Copy to output Directory" to "Copy Always"
It's a good idea to make the Wrapper project dependent on CLibrary so CLibrary gets built first, you can do that by right-clicking the Wrapper project, going to "Project Dependencies" and checking "CLibrary".
Now for the actual wrapper code:
ConnectSessionWrapper.cs
using System.Runtime.InteropServices;
namespace Wrapper
{
public class ConnectSessionWrapper
{
[DllImport("CLibrary.dll", CallingConvention = CallingConvention.Cdecl)]
static extern uint ConnectSession(uint handle,
[MarshalAs(UnmanagedType.LPStr)] string publicKey,
char publicKeyLen);
public uint GetConnectSession(uint handle,
string publicKey,
char publicKeyLen)
{
return ConnectSession(handle, publicKey, publicKeyLen);
}
}
}
Now just call GetConnectSession, and it should return 42.
Result:
Okay well, Open VS 2010, Goto File -> New -> Project -> Visual C++ -> Win32 -> Win32 Project and give it a name (HelloWorldDll in my case), Then in the window that follows under Application Type choose 'DLL' and under Additonal Options choose 'Empty Project'.
Now goto your Solution Explorer tab usually right hand side of VS window, right click Source Files -> Add Item -> C++ file (.cpp) and give it a name (HelloWorld in my case)
Then in the new class paste this code:
#include <stdio.h>
extern "C"
{
__declspec(dllexport) void DisplayHelloFromDLL()
{
printf ("Hello from DLL !\n");
}
}
Now Build the project, after navigate to your projects DEBUG folder and there you should find: HelloWorldDll.dll.
Now, lets create our C# app which will access the dll, Goto File -> New -> Project -> Visual C# -> Console Application and give it a name (CallDllCSharp), now copy and paste this code to your main:
using System;
using System.Runtime.InteropServices;
...
static void Main(string[] args)
{
Console.WriteLine("This is C# program");
DisplayHelloFromDLL();
Console.ReadKey();
}
and build the program, now that we have both our apps built lets use them, get your *.dll and your .exe (bin/debug/.exe) in the same directory, and execute the application output should be
This is C# program
Hello from DLL !
Hope that clears some of your issues up.
References:
How to create a DLL library in C and then use it with C#
NOTE : BELOW CODE IS FOR MULTIPLE METHODS FROM DLL.
[DllImport("MyLibc.so")] public static extern bool MyLib_GetName();
[DllImport("MyLibc.so")] public static extern bool MyLib_SetName(string name);
[DllImport("MyLibc.so")] public static extern bool MyLib_DisplayName(string name);
public static void Main(string[] args)
{
string name = MyLib_GetName();
MyLib_SetName(name);
MyLib_DisplayName(name);
}
The P/Invoke method has been described extensively and repeatedly, ok so far.
What I'm missing here is, that the C++/CLI method has a big advantage: Calling safety.
In contrast to P/Invoke, where the call of the C funtion is like shooting blind into the sky (if this comparison is allowed), nobody will check the function arguments when calling the C function.
Using C++/CLI in this case means normally, you include a headerfile with the functions prototypes you want to use. If you are calling the C function with wrong/to much /to few arguments, the compiler will tell you.
I don't think you can say in general which is the better method, honestly I don't like either of them.
I am trying to follow tutorial calling code from C++ into C#.
I followed the coding part correctly.
But when I run the code I get exception:
System.DllNotFoundException: 'Unable to load DLL 'SampleNativeLib': The specified module could not be found. (Exception from HRESULT: 0x8007007E)'
I create C# library as simple application file.
And C++ as dynamic .dll.
In the original tutorial (I also have full project file of it) in the C# project in the references there are no references to C++ .dll.
I would like to ask how C++ is referenced to C#?
The code of C#
using System;
using System.Linq;
using System.Runtime.InteropServices;
namespace ObjectPinning {
class Program {
[DllImport("SampleNativeLib")]
static extern int SetData([MarshalAs(UnmanagedType.LPArray)] int[] darray);
[DllImport("SampleNativeLib")]
static extern int DoCalc();
static void Main(string[] args) {
var data = Enumerable.Range(0, 10).Select(i => i + 1).ToArray();
GCHandle handle = GCHandle.Alloc(data, GCHandleType.Pinned);
Console.WriteLine(SetData(data));
Console.WriteLine(DoCalc());
Console.ReadLine();
GC.Collect();//Clean up any garbage object
Console.WriteLine(DoCalc());
handle.Free();
}
}
}
The code of C++:
// SampleNativeLib.cpp : Defines the exported functions for the DLL application.
//
#include "stdafx.h"
int* g_pData;
extern "C" __declspec(dllexport) int WINAPI DoCalc() {
int sum = 0;
for(int i = 0; i < 10; i++)
sum += g_pData[i];
return sum;
}
extern "C" __declspec(dllexport) int WINAPI SetData(int* data) {
g_pData = data;
return DoCalc();
}
My project file:
Download
Teachers File:
Download
My file
Teacher File
The exception you get is most likely because you didn't add the dll to the C# executable path. In the first step the application searching the dependencies in the exe directory, if not found, then it goes through the Window environment variables. That is why we don't need to copy the dlls when we use some of the Windows API function, because if you look at at your PATH variable, you'll have %SystemRoot% variable which links to your windows folder.
In C# you can't really reference C++ projects as you already know when adding another C# project, since you calling from managed code to unmanaged/native code.
Important note when you building your own C++ dll, make sure the compiler environment set to x32 bit, otherwise you'll get some other exceptions when calling C++ code from C#.
What actually expose the C++ function to allow for it consumed by other languages, is the:
extern "C" __declspec(dllexport)
On the signature of the function. So that gives you the power to do almost everything you can do with C++ also in C#/Java.
Is it possible to invoke a g++ executable file's function from mono in Ubuntu? Note that both C++ and C# code compiled in Ubuntu Operation System.
C++ application source:
#include <stdlib.h>
static int32_t Sum(int32_t a, int32_t b){
return a + b;
}
/*
*
*/
int main(int argc, char** argv) {
return (EXIT_SUCCESS);
}
C# mono application source:
using System;
using System.Runtime.InteropServices;
namespace MonoCsTest
{
class MainClass
{
[DllImport("/home/.../MonoCsTest/bin/Debug/testcpp")]
public static extern Int32 Sum(Int32 a, Int32 b);
public static void Main (string[] args)
{
Console.WriteLine (" 5 + 6 = " + Sum(5,6));
}
}
}
This throws DllNotFoundException
You need to compile the library as a shared library: a static library can't be loaded at runtime with P/Invoke.
The fact that you added a main() function suggests that you're compiling the code into an executable instead.
So the first thing for you is to learn how to compile a shared library, you can try something like:
gcc -shared -o libtestcpp.so testcpp.cpp
Then change the DllImport name to the path to the complete library name:
DllImport("/home/yourlogin/MonoCsTest/bin/Debug/libtestcpp.so")
The other mistake you made is not considering the C++ manadated name mangling: the simpler solution here is to export Sum() as a C function surrounding it with extern "C" {}.
To diagnose such mistakes it is often useful to enable the debug logging from mono using:
MONO_LOG_LEVEL="debug" MONO_LOG_MASK="dll" mono yourprog.exe
As long as a symbol is exported and Mono can understand the parameters (enough to marshal data to/from them), then yes, you can do this. I think the Mono pages on PInvoke actually mention that you can invoke functions exported by both libraries and executables, including an executable that embeds Mono.
You need to verify that the symbol is indeed being exported, and more importantly, that it is not mangled or you match that in the C# side. That's the spot I've had the most stupid problems with.
I am working on a project that requires some image processing. The front end of the program is C# (cause the guys thought it is a lot simpler to make the UI in it). However, as the image processing part needs a lot of CPU juice I am making this part in C++.
The idea is to link it to the C# project and just call a function from a DLL to make the image processing part and allow to the C# environment to process the data afterwards. Now the only problem is that it seems I am not able to make the DLL. Simply put the compiler refuses to put any function into the DLL that I compile.
Because the project requires some development time testing I have created two projects into a C++ solution. One is for the Dll and another console application. The console project holds all the files and I just include the corresponding header into my DLL project file. I thought the compiler should take out the functions that I marked as to be exported and make the DLL from them. Nevertheless this does not happens.
Here it is how I defined the function in the header:
extern "C" __declspec(dllexport) void _stdcall RobotData(BYTE* buf, int** pToNewBackgroundImage, int* pToBackgroundImage, bool InitFlag, ObjectInformation* robot1, ObjectInformation* robot2, ObjectInformation* robot3, ObjectInformation* robot4, ObjectInformation* puck);
extern "C" __declspec(dllexport) CvPoint _stdcall RefPointFinder(IplImage* imgInput, CvRect &imgROI,
CvScalar &refHSVColorLow, CvScalar &refHSVColorHi );
Followed by the implementation in the cpp file:
extern "C" __declspec(dllexport) CvPoint _stdcall RefPointFinder(IplImage* imgInput, CvRect &imgROI,&refHSVColorLow, CvScalar &refHSVColorHi ) { \\...
return cvPoint((int)( M10/M00) + imgROI.x, (int)( M01/M00 ) + imgROI.y) ;}
extern "C" __declspec(dllexport) void _stdcall RobotData(BYTE* buf, int** pToNewBackgroundImage, int* pToBackgroundImage, bool InitFlag, ObjectInformation* robot1, ObjectInformation* robot2, ObjectInformation* robot3, ObjectInformation* robot4, ObjectInformation* puck) { \\ ...};
And my main file for the DLL project looks like:
#ifdef _MANAGED
#pragma managed(push, off)
#endif
/// <summary> Include files. </summary>
#include "..\ImageProcessingDebug\ImageProcessingTest.h"
#include "..\ImageProcessingDebug\ImageProcessing.h"
BOOL APIENTRY DllMain( HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved)
{
return TRUE;
}
#ifdef _MANAGED
#pragma managed(pop)
#endif
Needless to say it does not work. A quick look with DLL export viewer 1.36 reveals that no function is inside the library. I don't get it. What I am doing wrong ?
As side not I am using the C++ objects (and here it is the C++ DLL part) such as the vector. However, only for internal usage. These will not appear in the headers of either function as you can observe from the previous code snippets.
Any ideas? Thx,
Bernat
It seems you are confused about which files to include in your DLL project vs your console project. If it is true that "The console project holds all the files" then this is your problem.
Your DLL project needs to include the cpp file which has the __declspec(dllexport)s. As you describe it, you have included your RefPointFinder() & RobotData() functions in the console project. In other words your DLL has no functions in it whatsoever, regardless of whether anything is exported.
Just including the .h files in the DLL main file does nothing by itself. It doesn't include these functions in the DLL.