.NET DLL depends on a regular DLL

[searope]

Hi,
I have a .NET DLL I'd like to use in my strategy. I was able to reference it from NinjaScript. But the DLL references another DLL which is not .NET so it cannot be added from the NinjaScript Editor's context menu. I've placed both DLLs in the bin/custom folder, indeed. My script compiles ok, but when I try to add it to a chart, it throws exception from where it uses the non-.NET DLL as if the .NET DLL cannot find it.
I've created a WPF project using .NET Framework 4.8 and the combo of the DLLs works just fine there.
Is there a way to make it work?
Thanks

[NinjaTrader_Jesse]

Hello searope,

non .net dll's are not something which you would add as a reference.

Placing the file in the bin/custom would be required however depending on what is inside the dll may cause it to not be able to be used. That heavily depends on what language that dll was written in and if its made for the correct architecture you are using 32bit/64bit.

This is really an area which our support couldn't help much with besides suggesting that you set up an external development environment in visual studio to further test how you need to utilize the dll in your own custom code. That would involve creating a new .net framework WPF desktop application project using C# 4.8. From that project you can add your dlls that are able to be referenced and make code that uses them to call their functions. That would let you test the other dll to see how you need to use it. That would also let you see what specific settings are required to allow that to work, for example if you had to make a 32/64/anycpu project to get it to work. You may need to rebuild the dll for a specific 32/64 for NinjaTrader to be able to use it.

If this is something you did not make you will need to refer back to the source to find out what language the dll is made in and what architecture it was built for 32/64, NinjaTrader is not anycpu but uses a specific 32 or 64 bit exe meaning any dlls that are not .net would need to match the platform architecture.

[searope]

Thanks for the hint. As it turns out the native DLL was 32-bit one so switching to x32 version of NT8 did the trick.