Tuesday, August 14, 2012

Calling R From C# .NET (CSharp DotNet)

As mentioned in a previous post about Calling R From VB6 VBA, I've been using 7Bit's very useful utility to call R from VB6. It is so useful that I needed to have the same capability in C#. So I took my VB6 interface and translated it to C#.

Originally the mt4R.dll tool was created to interface to R from Metatrader. Knowing that this is a windows DLL, therefore mt4R can be accessed from a number of languages, including VB6 and now C#, if a suitable interface is used.

A simple class interface was born in C# that allows .NET users to access R via calls to the mt4R dll. I'm about to embark on a project that will use this newly minted interface in C#.

I've been using this for some time in VB6 but as I'm moving more of my development to C#, and I've decided it was time to share with everyone else. So I put together a simple demo application that shows how to access mt4R.dll in a simple C# Windows form application.

You can download Calling R From CSharp DotNet. (Please follow the instructions on that page) for use in your own projects.

C# / .NET developers don't need to worry about transposing matrices to get them to work in R. R and C# arrays are set up the same way:

A[row, column]

Please let me know if you have any comments, questions or problems getting this code to work.

5 comments:

Patrick White said...

If you just downloaded the sample and are having trouble getting it working, either redownload, or change the Platform target to x86 from the Build tab in TestMT4R Properties.

Anonymous said...

It is not possible to download

Patrick White said...

Post your email address and I'll delete your post then send you the file.

Ben said...

Hey, do I need to add the .dll to the windows/system registry or can I just add the reference and add it as a compiled resource?

Ben said...

So I found a way to avoid needing to copy the .dll into windows/system - just copy it into the bin/debug folder of your project (assuming VS is your IDE). It seems to work this way without the .dll in windows/system. Probably because when DLLImport is called and it looks for the .dll it just says the name, which _should_ default to the /debug directory.

Can you see this causing problems down the line?