references 32 bit and 64 bit

[zweistein]

Hello,

Ninja7 is a big step towards a unified coding platform indipendent of 32 or 64 bit environment. Excellent.

However, a typical case is that indicator or startegy code (which itself is platform indipendent)mat rely on external dlls which are platform specific.
Typical case would be an external C++ library compiled in 2 versions, for x86 and for ia64.

The references in NinjaTrader (config.xml <References> section) is however unique for both architectures.
This will create problems when a user will (under 64) switch from the 64 bit version NinjaTrader to the 32 bit Version NinjaTrader, because the references will be the same for both.

For example:
<string>
C:\Users\A\Documents\MyLibary\MyLibray_ia64.dll
</string>


Proposal:

Can you add a section
<References32>

and
<References64>


to the Custom.xml and load
<References32> additionally when running Ninja32bit and
<References64> when running Ninja64bit

the existing <References> section would maintain existing behaviour!

Any other ideas how to resolve the reference for the different platforms?


Regards

Andreas

[NinjaTrader_Dierk]

<references> section of Config.xml only holds .NET assemblies (NO native code DLLs). Thus your suggestion does not apply.

[zweistein]

Hello Dierk,

I see in my Ninja64 bit installation that you have specialized dll files like
Infragistics2.Win.v8.3.dll
NinjaTrader.Core.dll
...

in directory:

..\Program Files\NinjaTrader\bin

and also in

..\Program Files\NinjaTrader\bin64


Currently I use Ninja32.

But using Ninja64, where would I reference the above files?
I would reference ..\Program Files\NinjaTrader\bin64\Infragistics2.Win.v8.3.dll etc?

Or are the 2 files in bin and bin64 identical?


regards

p.s. for C++ compiled one could use a wrapper C#.net code that resolves into 32 or 64 bit code.

[NinjaTrader_Dierk]

Unfortunately this is beyond what we provide support for. You are touching a very complex area on how NT would load references files. For that reason I even will not provide any hints since this might guide you to the wrong direction.

[zweistein]

Please RE-read my suggestion!

as you see from the example given below the case that C# NET assemblies are specialised for processor architecture do exist!

My suggestion makes sense here and it would be a clean solution for a proper 64 bit integration. It is also easy to implement!


regards


P.S. I see only 3 loading scenarios here: (Maybe I am wrong, but binging MSDN will give the answer)
Ninja 64 dlls loading (->bin64)
Ninja32 dlls loading in Windows64 environment (->bin\X64)
Ninja32 dlls loading in Windows32 environment (->bin)

[NinjaTrader_Dierk]

Thanks for your suggestion. We'll add it to the of future considerations.

Note: Any assembly (embedded in a NS archive) created by File->Utilities->Export NinjaScript would not exhibit any issue at all in that regard