I developed a MATLAB function, and I'm looking for a way to call that function from another C# application and pass some parameters to it and get the results in the C# program.
I heard that I can use Dynamic Data Exchange (DDE) or COM objects, but have can I do it?
There is nice example in the MATLAB Central.
It shows three ways on how to communicate with MATLAB:
COM
MATLAB .NET Bulider
MATLAB compiler
COM (I do not have any experience with it)
Cons: MATLAB is required to be installed on the target computer.
MATLAB .NET builder compiles your MATLAB code to the .NET assembly and you can use it directly.
Pros: MATLAB is not required to be installed on the target computer
Cons: It's expensive
MATLAB compiler compiles your MATLAB code into a C/C++ library or EXE file. You can use it through P/Invoke.
Pros: MATLAB is not required to be installed on the target computer
Cons: It's expensive, a lot of P/Invoke.
There is a third option: delegates. Starting MATLAB -> load .NET assembly -> execute .NET function with delegate handle to a MATLAB function.
There is a great example on this site on setting up everything. You can use MATLAB .NET deployment tool.
You need to
Install MCR (Matlab Compiler Runtime).
Deploy your Matlab function to .NET Assembly using Matlab Deploy
Tool. This will create a .dll file.
Add .dll reference inside your .NET project.
Add reference to MATLAB.NET.
The advantage of this method is that the target machine does not require MATLAB to be installed, but on the downside the execution is quite expensive.
Related
Is C++ source code required to build a .NET wrapper or static libraries *.lib files are just enough?
We plan to use SWIG.
Thanks.
w.r.t. your question asking specifically about static-libraries *.lib:
Is C++ source code required to build a .NET wrapper or static libraries *.lib files are just enough?
I doubt you actually intend to wrap a static-lib: Statically-linked libraries generally aren't redistributable nor portable (e.g. the authors of closed-source static libraries need to build them every time a new supported compiler comes out, e.g. you can't use a GCC lib with VisualC++ 2017, and an x64 VisualC++ 2017 lib won't be compatible with an x86 VisualC++ 2015 project) - and even if you loaded a *.lib into your process' memory and jumped into a known function address inside the lib's image, it would immediately break because the static library's code will have references to certain memory addresses (e.g. of string-constants) which aren't yet relocated - you'll get an segfault (or "Access violation" on Windows) crash if you're lucky (if not, it'll definitely corrupt your process' memory space before being detected).
P/Invoke in .NET Framework and .NET on Windows (i.e. using [DllImport]) only supports DLLs (Dynamically Linked Libraries), not statically-linked libraries.
You can also call into native code if the native code is available as a COM object, or can be accessed through platform features like OLE, WMIC, ADSI, etc (assuming your code's process is the same ISA as the native code you want to call, as it will still be loaded into your process, which is why you can't use 64-bit Office Excel to open databases where only a 32-bit OLE-DB or ODBC driver is available).
When a library is available as a *.lib then you need to make your own native host first - a simple C/C++ Win32 (PE) EXE or DLL that re-exports all of the useful functions from that *.lib will be sufficient - because then those exports can be imported by C#/.NET.
But in general:
If you are exporting COM objects to .NET then you don't need both the source-code files (*.c, *.cpp) or header files (*.h and *.hpp), only the IDL files or *.tlb (Type-lib) which the compiler will generate for you.
If your native code is also available through other platform features like OLE, ActiveX, COM Automation (IDispatch), ODBC, OLE-DB, ADSI, WMI, etc then you wouldn't be using [DllImport], and those platforms all either provide a standard interface (like ODBC and OLE-DB)
But generally speaking, no - you do not need the source-code (i.e. both *.c and *.h files) to create a .NET wrapper around native code exported from a native DLL and imported into .NET using [DllImport].
But you will need the header files (*.h) from a C/C++ project in addition to knowing the compiler settings (for finding out things like calling-convention, parameter marshaling info, etc) and a PE inspector (to verify the exported functions are at least present in the DLL you want to load).
Don't forget to ensure you provide both x86 and x64 native DLLs for all functionality if you're compiling your C#/.NET code for AnyCPU (tip: Using a 32bit or 64bit dll in C# DllImport )
I am trying to use this code in a Unity project, but it seems the implementations of COM Interop in Mono/.NET differs, which causes the code to fail or crash. Running the code in .NET works fine, but running it with Mono 2.0 (outside of Unity) fails in the same way as in Unity, suggesting it is a problem with Mono in general and not Unity.
If I compile and run the code as-is, it fails because the type cast from MMDeviceEnumerator to IIMMDeviceEnumerator fails. When decorating all interfaces with [ComInterop], the cast succeeds, but the call to GetDefaultAudioEndpoint crashes Unity/Mono with an Access Violation.
It is hard to find good documentation of COM Interop on Mono in general - and particularly so regarding such an old version. Is it at all possible to get this running?
Wrap the COM functions in C funtions and call the C functions via P/Invoke instead. This can be done in two steps:
Create a VC++ project that wraps the functions you needed in wasapi. Expose them via a module define file or __declspec(dllexport). Build the code into a dll that exposes the functions you need.
In your Unity3D project, access them via P/Invoke.
Here is an example. In your case, just use the COM code in the C/C++ part to do what you want.
Mono 1.0 and Mono 1.1.xx do not have support for COM.
Stop trying with Mono, Mono is for platform independence and COM Interop is Microsoft only. Use open source SDKs for Video Playing or better invoke apps from command line like vlc to play, encode etc.
Ahead of Time Compilation or AOT is a feature of the Mono runtime code generator.
mono --aot program.exe
This will generate a file called "program.exe.so"
How can i load this shared object file in php script and access the class objects and methods. ?
Thanks
The native library still needs to be loaded inside an AppDomain (i.e. the Mono VM/runtime) in order to run, it is not a native library as such.
If you must I'd suggest looking at
whether php supports COM interop (I don't use php, but I'd reckon the chance exists). This would be good since you could use that and profit from OO interface exposure
Use Swig which has support for C# some time now
Alternatively, use mkbundle, and/or create a native shared library that embeds a Mono VM. The shared library wrrap around the C# interface using a "C" native API's.
The Phalanger project should be able to do this. You can compile your php code with mono and also integrate with .net from php.
What is a way I can a native EXE using C#, I want to compile a basic EXE which will run without the need for the .net framework. I've heard of ngen.exe can anyone give me examples of ngen.exe or any better ways. Also I will have a runtime for the application being generated how can I place it into the application so anybody who is using my language can use its features.
Can't do that. Anything written with C# will require the .NET framework to be installed on the machine in which it runs. NGEN is just an optimization; it does not remove the need for the framework.
To do this you'll need C++ or some other language that does not require a runtime.
I want to use c++ library in a c# project. Is there any wrapper tool to import all classes automatically?
SWIG can help create a wrapper consisting of two parts, one C++ sided, and one C# sided.
It needs a bit of work to set up the correct generation files though.
An alternative that requires more manual coding is C++/CLI.
For pure c apis I prefer p/invoke over either of them. There is a program to automate conversion of c headers. If I recall correctly it's called something like "P/Invoke Interop Assistant" or "Interop Signature Toolkit".
There is also mono/cxxi which looks pretty cool.
The procedure of using native .dll's in .Net is called P/Invoke. Look at http://pinvoke.net/ for some examples.
Note that you must match the build target with the version of the .dll. So for x86 .dll's you need to lock your project to x86, same with x64.
Note2 that you only need to lock the executing project (.EXE), not any additional projects loaded from the .EXE. .Net will automatically match .Net .dll's to CPU target type if they are set to ANY.
From http://social.msdn.microsoft.com/forums/en-US/clr/thread/c957959e-0f0c-422e-a5be-4ccfdd12e63d: You can use "dumpbin /exports <name_of_your_dll>" or dependency walker (depends.exe) to look at the exported symbols. They are both included in Visual Studio.
Additional comment on C++: While it is relatively simple to use native .dll's written in C from .Net, using C++ binaries that make use of objects is not as trivial. One way to solve that is to use a C++ CLI project a binding between managed .Net code and unmanaged C++ library.
If this is unmanaged code then you could use P/Invoke. Another possibility is to use the C++/CLI extensions to compile the code into a managed assembly that you could directly use.