After peeking around the internet it looks like it is possible to interop between C# and Matlab. I am wondering if anyone has had success with it and what they did to do so. If possible somehow pulling it off without the use of COM. Thanks for your time.
Beginning with the R2009a release of MATLAB, .NET objects can be accessed from MATLAB:
http://www.mathworks.com/help/techdoc/matlab_external/brpb5k6.html
In older versions of MATLAB, it is possible to access .NET objects from MATLAB using CCW:
http://www.mathworks.com/support/solutions/data/1-5U8HND.html?solution=1-5U8HND
and the MATLAB engine from .NET:
http://www.mathworks.com/access/helpdesk/help/techdoc/index.html?/access/helpdesk/help/techdoc/matlab_external/f135590.html#f135616
You can also use the MATLAB Builder NE to wrap m-code into .NET assemblies.
http://www.mathworks.com/products/netbuilder/
Yes, quite possible. Though I ended up using the C interface and calling into that using a mixed-mode DLL (and getting C# to call into that... but that was because I was also interfacing with some other C code). It's quite straightforward. On computers where you want to run your program, you'll need to install Matlab Runtime MCRInstaller.exe.
edit: removed broken link
Yes, I managed to do that and it was mostly painless.
You'd have to compile your MATLAB code for .NET (as explained in pervious answers), run MCR installer, reference MWArray.dll and the complied code dll in your .NET project and off you go.
The only annoyance was the casting (and sometimes multiple castings!) that the interface forces on you (using explicit in the cast operators)
There is a free and open source .NET wrapper for Matlab, and it is very simple:
http://www.codeproject.com/KB/dotnet/matlabeng.aspx
I use this.
In the R2009a pre-release you can call .net assemblies from MATLAB.
I'm not sure how much this applies to you but try looking into matlab executables or MEX Basically, it's really easy to write a program in C or FORTRAN, include a few libraries and functions, and then you can use you C or FORTRAN function in matlab
If you're willing to spend money this may be what you need:
http://www.mathworks.com/products/netbuilder/
It can generate wrappers for Matlab code that allow it to be called from both .NET and COM.
Related
At the moment, I am working in a C++ environment. There are many in house programs, SDKs, and DLLs. What I want to know is, moving forward, would I be able to wrap that code into something C# could use? I'm still learning about wrapping code for other languages, and haven't found a decent source for going from C++ to C#.
As far as cross-language interop goes, the C#-C++ interop is actually quite usable. Check out the official documentation. "Managed" is Microsoft-speak for everything in the .NET runtime, i.e. your C# code; "unmanaged" or "native" means your C++ code.
Microsoft has extensions to C++ called C++/CLI that make it easier to build wrappers for .NET languages.
I have a c# dll that needs to be called in Java.I see that there is a method using jni to call c++ dlls.How can I do it for a c# dll..Please help..I couldnt find any good material on this
From here:-
IKVM.NET is an implementation of Java for Mono and the Microsoft .NET
Framework. It includes the following components:
A Java Virtual Machine implemented in .NET
A .NET implementation of the Java class libraries
Tools that enable Java and .NET interoperability
You can use Java Native Interface. Or you can create a COM assembly from the C# code and use J-Interop to invoke it.
If you have C# dll sources you need to use maybe the better way will be to translate it to Java using some tools like GrassHopper.
According to GrassHopper key feature explanation it can convert MSIL to Java bite code. So can use without sources of c# dll
Check this: http://www.javonet.com
If you look for quick and easy solution then Javonet should work fine for you. It is light counterpart of IKVM and J-Integra works also as native bridge.
All you have to do is:
add Javonet.jar do your project call
call Javonet.addReference("yourlib.dll")
use your .NET library like it was almost JAVA package
Sample:
NObject obj = Javonet.New("yourDotNetClass");
obj.invoke("YourMethod","arg1", 2);
The syntax is not strongly-typed and works like reflection but gives you fastest access to any custom .NET code, third-party libs or .NET framework as no changes are needed on .NET side. If you need it is also possible to implement custom strongly-typed wrappers.
I do recommend this bridge as in my opinion it is easiest to quickly get things done but also other native bridges are worth checking as this is best approach for such case.
I would avoid going into custom JNI or COM unless you have a lot of time and you just want to learn, if you need quick and reliable solution take one of third-party bridges.
I've been writing a program in C++ and noticed there is a library in C# that someone else wrote that I would like to link in to my code.... but I'm not sure how to do that. Can someone suggest something? Doubt this matters, but I'm using Windows 7 with MSVC2010.
Thanks in advance!
You can try compiling your C++ program in C++/CLI mode. Then the compiler will produce a .NET executable which can create C# objects and use their methods.
C++/CLI is discussed here: C++/CLI
If you're familiar with COM you could access the .NET library through COM. If the library doesn't provide COM interop out of the box you could write a wrapper around it using C# and expose that through COM.
If you're going to pull in a .NET library you should be aware that it requires a .NET runtime which may take up valuable resources. If you ware building the application in C++ for performance reasons, maybe you're better off porting the parts of the library you need to C++.
I'm currently in a project that need to work both on Mac and Windows. We are using standard portable C++ for all the application logic. However, since we want the app to feel totally native on both platform, the GUI will be written with C#/WPF for Windows and Objective-C/Cocoa for Mac.
However, for the windows part, I am wondering what is the best way to use the C++ code with C#. C# is managed, and I know that we can use managed C++ too. However I worry that using C++ inside the CLR may introduce unexpected bugs, or that we will need to put an awful lot of #ifdef WIN32 everywhere in the C++ code to make it work both with the managed CLR and the unmanaged environnement of Mac OS X (note that we sure expect to put some ifdef, but we'd like to keep it under control if possible). So basically, what is the best way to use the C++ code with the C# code? Right now, I'm thinking of three solutions
1- Compile the C++ as C++/CLI and directly use the classes and function from C#.
2- Compile and wrap the C++ in an unmanaged win32 dll and call it from C# using DllImport
3- Wrap the C++ in a COM wrapper and use the .NET COM Interop to link it with C#
Which one is the best way? Or, if there is a better solution, what is it?
C++/CLI has several restrictions over standard C++ that don't always make it easy to recompile standard C++ as C++/CLI. Keep in mind that you'll have to distinguish 'managed' and 'unmanaged' pointers, for starters. As these are using different symbols, you've got your first set of #ifdefs right there. And then you get to ref and value classes and all that sort of fun.
You can however use C++/CLI to bridge the gap between native code and the .NET world. The last time I did something along the lines of what you're planning to do, I used C++/CLI to write the bridging layer that did the necessary translation and conversion work between .NET types and classes and the native world. The C++/CLI layer can obviously be used from any .NET language.
You can't always use (2) - this depends very much on the data types you're trying to exchange between the two worlds. The .NET marshalling code is pretty good at dealing with C PODs but anything more complicated and you've got a problem.
(3) is overkill IMHO and introduces another point of failure, plus you're then doing .NET <-> COM <-> native instead of the simpler .NET <-> native if you created your own bridging code. Not to mention that you add complication to your code that won't benefit the other OS you're targeting, namely OS X.
Our development team has been using C++/CLI compiled code with ASP.NET and WPF front ends for while now.
The first major issue we had was build time. The code base would be 150k lines (40+ projects) and took forever to link (due to linker issues we could not build the individual projects as DLL's). We were only able to resolve this issue by wrapping the code with managed C++ classes and building our projects as assemblies.
The second major issue was performance. We originally compiled with /clr (before pure option existed) and this resulted in double thunking of most of our calls that occurred in the managed C++ layer. We fixed this by switching to /clr:pure. By doing so we ran into an
issue where our assemblies resulted in having too many 'global' methods in the assemblies so they would not load. We had to split our assemblies further to solve this issue.
Best and easier way is to do it with .NET <-> COM because COM has much stronger bridge compared to native dll access inside .NET because it may lead to lots of memory issues and lots of troubleshooting time. Its easier to test COM inside any MFC project and get the trace information for debugging and when the component is ready it can be easily used inside .NET.
CLI will not let you use all features and unfortunately its fairly new so less documentation is available and you will not get good support for your questions.
Win32 dll and DLLImport has problems mainly to troubleshoot, because the exception thrown inside Win32 dll will not travel further along the stack instead it will simply crash and you will not get the reason. Where else in COM you can catch exception internally and the COMException thrown inside .NET will not crash your entire application.
COM will be little slower in performance, but it will be more organized and good design pattern to develop.
Can you run C# code from c++?
and How?
If you're C++ code is "managed" C++ that's built on the .NET common language run-time (CLR), then it's easy to reference a C# assembly and invoke public classes and methods. If, however, your C++ code is "native" (not built on the CLR), then you'll want to register your C# assembly for COM interop and invoke the COM object from your C++ code. There's an MSDN article that covers all the gory details:
http://msdn.microsoft.com/en-us/library/w29wacsy(VS.80).aspx
There's also a good article on CodeProject by Nick Parker called "Exposing .NET Components to COM" that you may find useful.
You can use unmanaged C++ to run a .NET application, but how difficult it will be will depend on which version of .NET you are using.
When I did this with .NET 2.0 it took me two solid weeks to get it working.
The answer in this page gives guidance as to which programs are needed to do this.
http://www.pcreview.co.uk/forums/thread-1225474.php
The other option that you have, depending on what you're trying to do, is to host the CLR in your application which allows you to more tightly integrate the C# code than is possible by going through COM. You can read an overview of doing this in this MSDN Magazine article.
With C++/CLI, yes (formerly Managed C++ -- which had different extensions to the language).
yes, you can use COM to call .NET
You can call .NET code without COM by using the mscoree.dll ClrCreateManagedInstance Function. You need to supply the assembly qualified name of the type name you want to create, in the pTypeName parameter.
From memory, in some cases you may need to add the ComVisible attribute to the interfaces or classes you wish to access using ClrCreateManagedInstance(). However this does not require you to also register your class or any of the other messy deployment issues that go with COM.
I'm guessing the answer that would really be useful to Chad is:
Yes, it is most definitely technically possible to run C# code from C++. However, if the other answers on this page sound like they are going over your head, then you are nowhere near experienced enough to actually do this. It is pretty difficult to pull off, all things considered, so unless you really need to be running C# code from C++, it might be best to just rewrite the C# code as C++.