Vendor External C DLL

[tradetree]

This post is to address an issue with an external DLL written in C. On another .NET trading platform I have this working, but so far it has not worked in NT. I have a DLL from a vendor in C:\Windows\System32.

I put this using directive at the top of my strategy file:

using System.Runtime.InteropServices;		// for DllImportAttribute

Then this class definition:

public class JRC
{
	[DllImport("JRS_32.DLL")]		// declares function as part of external DLL
	public static extern int JMART(double dSeries, double dSmooth, double dPhase, ref double pdOutPut, int iDestroy, ref int piSeriesID);
}

Then call it here:

private int iSeriesID;
double null_ref = 0;
 int intErr = JRC.JMART(0.0, 0.0, 0.0, ref null_ref, 0, ref iSeriesID);

If I don't add a reference to C:\Windows\System32\JRS_32.DLL it compiles, runs, but acts like nothing was called. If I add the reference I get a compile time error:
Metadata file C:\Windows\System32\JRS_32.DLL could not be opened. "An attempt was made to load a program with an incorrect format".

[tradetree]

I also tried creating my own C# DLL to wrapper the C DLL. My DLL built without error in Visual Studio. The NT strategy invoking the external static class also built without issue within NT, given the reference to my wrapper DLL. When I ran it the strategy exited with this error in the log file,

"Error on calling 'OnBarUpdate' method for strategy 'ThreefoldChannelJMA/aaf79df5364e47fd91fe8e971f86a846': Could not load file or assembly 'JRC, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified."

[NinjaTrader_Bertrand]

tradetree, taking it a step back - why would you try to implement a custom solution for the Jurik toolset? This is already provided to the UT toolset via the NT vendor dll wrapper functions per default. That's the route I would go, as it would provide a tested and supported way.

[tradetree]

Good suggestion. It is a possible path, but I would prefer not to. I develop trading systems and I use multiple platforms. I look for ways to share as much code as possible, and this is done through external DLLs. I have the Jurik tools working under another platform using .NET. Their editor looks quite similar to NT, with references etc. I don't understand the difference? For this reason I purchased the C version of the Jurik tools to have flexibility.

Do you have any ideas regarding the error?

[NinjaTrader_Bertrand]

I see, would there be two versions offered for 32 vs 64 bit? Could that be perhaps an issue? Does the dll depend on other dll's that might be potentially missing from the setup?

[tradetree]

I have a 64 bit DLL from Jurik and I'm using 64 bit NT. I am building my wrapper DLL with .NET 3.5. I talked to Jurik and they suggested I try creating a C++ DLL. Can I reference a C++ DLL from within my NT strategy? Any other ideas?

[cdjindia]

I have a 64 bit DLL from Jurik and I'm using 64 bit NT. I am building my wrapper DLL with .NET 3.5. I talked to Jurik and they suggested I try creating a C++ DLL. Can I reference a C++ DLL from within my NT strategy? Any other ideas?

ur query got me thinking....

In your case, My hunch is that Ninja is looking in different places for DLLs.

In another .NET C# project (non Ninja) , I've used function LoadFile in
System.Reflection.Assembly namespac to dynamically load DLLs to provide some interface implementation. Reason for doing it that was that in that project, we could load infinite number of such DLLs (as long as machine did not go weak in its knees and rolled over). Each interface is just a rehash of old-school polymorphic implementation. Nothing fancy..


If that does not work, there used to be #import preprocessor directive in C and C++ world and you could try with its .NET equivalent.

[NinjaTrader_Bertrand]

I have a 64 bit DLL from Jurik and I'm using 64 bit NT. I am building my wrapper DLL with .NET 3.5. I talked to Jurik and they suggested I try creating a C++ DLL. Can I reference a C++ DLL from within my NT strategy? Any other ideas?

Would you have the same error reported if you for example copied the dll to call into Nt's standard 'DLL to load' Documents > NinjaTrader7 > bin > custom folder?

An unmanaged C++ dll could be called from a C# project as well (even if it could not be directly referenced), however generally this would not be an area we could really support.

This potentially could assist working it out - http://msdn.microsoft.com/en-us/magazine/cc164123.aspx

[tradetree]

This is the perfect solution cdjindia. It took some research but that gave me direct control over where it looked and how to load it. I wrapped the LoadFiles in a class method so it was nice and clean. It is working much more efficiently than I had thought given all the redirection. The optimizer must be doing a good job of resolving the calls. Thanks a bunch for the tip.

And Bertrand, thanks for the ideas. The above referenced solution is working so I'm moving forward for now.

ur query got me thinking....

In your case, My hunch is that Ninja is looking in different places for DLLs.

In another .NET C# project (non Ninja) , I've used function LoadFile in
System.Reflection.Assembly namespac to dynamically load DLLs to provide some interface implementation. Reason for doing it that was that in that project, we could load infinite number of such DLLs (as long as machine did not go weak in its knees and rolled over). Each interface is just a rehash of old-school polymorphic implementation. Nothing fancy..


If that does not work, there used to be #import preprocessor directive in C and C++ world and you could try with its .NET equivalent.