Nasty error after binding new DLL

[molecool]

The way that I showed is just my preferred method because the namespce is self-contained in the class file, so when I export the class file, I am guaranteed to have the relevant namespace available. That way, there is no need to inherit from anything.

If you prefer you can separate all your custom namespaces into a single file, without any class code, or even with an unnecessary empty class. Of course, then you do have to include that file in any export which uses an object defined in the file, but that file need contain no code, other than the namespace definitions and contents.

The point is that you do not need to separately bind any class as an extention to NinjaTrader, in order to use a namespace that is defined in said file.

I was aware of your OOP background, so I only suggested that you read the whole thread, precisely because I thought that you are the kind of person, with enough knowledge, who would see that we really have discussed many of the nuances, even as they might differ from the implementation in Java.

Don't get me wrong mate - I always appreciate your contributions. Just didn't feel that the core problem was being addressed as it should (not by you necessarily) as we should be able to do what I attempted. Alas we work around these issues as we always have ;-)

I totally get what you're saying about the binding, no argument there. If I define a namespace somewhere all I have to add is a 'using' statement in my indicator/strategy. My point was that the file containing the definition will have to be included when I export my indicator/strategy. And that sucks a bit as simply packaging a DLL would be more elegant. UNLESS NinjaTrader is able to somehow extract/package the namespace and the definition implicitly - if that is possible in NT or C# then I'm not aware of it. I hope you catch what I'm saying...

[koganam]

... And that sucks a bit as simply packaging a DLL would be more elegant. UNLESS NinjaTrader is able to somehow extract/package the namespace and the definition implicitly - if that is possible in NT or C# then I'm not aware of it. I hope you catch what I'm saying...

You are spot on. You must provide the namespace definition file in the export package. No implicit recognition of namespace entities. I will point you to one particular post that I wanted you to be aware of in the thread that I last referenced.

ref: http://www.ninjatrader.com/support/f...33&postcount=6

Note how this is true, even if you use the self-contained method that I prefer. The issue is in this case not the availability of the namespace in the dll, but in the cs file that is used to contain and iterate through the running instances. It needs the namespace to be able to reference the constructor, and NT does not put anything other than the NT default namespaces in that separate, linked cs file. IOW, when you export as a dll, NT separates out the "magic code" that it sticks at the end of the indicator, that it warns us direly not to touch, and that code needs to be able to see the namespace.

The only way to get quasi-implicit recognition of entities is if you define them in the Global namespace. You know what issues that carries. Essentially, if you do as NT says to do, then you must provide that class file that carries the definition in your Global namespace, to any export that you do that needs the defined entity, whether or not you want to give away that class that is in the file..

[molecool]

You are spot on. You must provide the namespace definition file in the export package. No implicit recognition of namespace entities. I will point you to one particular post that I wanted you to be aware of in the thread that I last referenced.

ref: http://www.ninjatrader.com/support/f...33&postcount=6

Note how this is true, even if you use the self-contained method that I prefer. The issue is in this case not the availability of the namespace in the dll, but in the cs file that is used to contain and iterate through the running instances. It needs the namespace to be able to reference the constructor, and NT does not put anything other than the NT default namespaces in that separate, linked cs file. IOW, when you export as a dll, NT separates out the "magic code" that it sticks at the end of the indicator, that it warns us direly not to touch, and that code needs to be able to see the namespace.

The only way to get quasi-implicit recognition of entities is if you define them in the Global namespace. You know what issues that carries. Essentially, if you do as NT says to do, then you must provide that class file that carries the definition in your Global namespace, to any export that you do that needs the defined entity, whether or not you want to give away that class that is in the file..

Eeek indeed - since the empty indicator I defined is just a placeholder it's probably as clean as it gets inside Ninja and I don't mind anyone getting that as it only contains a few enum definitions. Not a big deal - but like you I'm a bit of a pain in the ass purist and would have preferred to do it the 'right way' - and if it's just to stroke my inner OOP nerd's ego ;-)