CS Files in strategyanalyzerlogs folder

[ChazJ]

I have noticed that the CS source file of a strategy is stored in the strategyanalyzerlogs folder after a backtest and / or optimizer run. The XML file contains an entry named 'NinjaScriptFile' which points to the CS file in the folder.

I am now working on a new strategy and testing it in Strategy Analyzer. But I have noticed that I am not getting the CS file after running a backtest or optimization. I checked the XML file produced after a run, and it does not contain the 'NinjaScriptFile' entry.

What would cause this to happen?

Thanks,

Charlie

[NinjaTrader_Kate]

Hello ChazJ,

Thank you for your post.

If a strategy is part of a protected compiled assembly the .cs file would not be generated. Is this a strategy you've created yourself or one you've received from a third party? Is the strategy code visible in the NinjaScript Editor?

If you test with the Sample MA Crossover that is built into NinjaTrader, do you see the .cs file generated?

If this is a strategy you've created yourself and you're seeing that .cs file with other strategies, we would want to see a reduced example of the script. You may omit any code unnecessary to reproduce the behavior. You can either attach it to your reply here, or email it to platformsupport [at] ninjatrader [dot] com. If you email it in, please include 2598518 Attn Kate W. in the Subject Line of the email.

Thanks in advance; I look forward to assisting you further.

[ChazJ]

Hi Kate,

This is my own strategy. I have created many and this is the first one that exhibits this behavior. The only thing different from my previous strategies is that I have restructured everything such that I have a base strategy class which handles all order management, debugging and other trace output, and other common functions. The actual strategy logic is contained in a strategy class that inherits from my base class (which inherits from the Strategy class, which, in turn, inherits from StrategyRenderBase.

Could this be the problem?

[NinjaTrader_Kate]

Hello ChazJ,

Thank you for your reply.

Inheritance within indicators and strategies is not supported and utilizing such a structure, while possible, is known to cause issues in certain places. This certainly sounds like what's occurring in your case - the .cs file simply cannot be generated due to the structure of the strategy you're using.

Please let us know if we may be of further assistance to you.

[ChazJ]

Rats!! Looks like I'll need to refactor back.

Thank you

Charlie

[MojoJojo]

All my strategies inherit from an abstract base class and I do get a .cs class and an .xml with a NinjaScriptFile entry pointing to it.

[ChazJ]

Interesting, and thanks for responding MojoJojo.

So what I am doing is this:

namespace NinjaTrader.NinjaScript.Strategies
{
public abstract class MyStrategyBase : Strategy
{
(Code for debug, trace, order handling, common functions, etc.)
}
}

then in a separate file:

namespace NinjaTrader.NinjaScript.Strategies
{
public class MyStrategy : MyStrategyBase
{
(Code for detecting entries and exits)
}
}

Is this a similar structure to what you are doing?

[MojoJojo]

Your structure is just like mine.

    public abstract class AbstractStrategy : Strategy

Utility functions, common parameters, trade management

    public class SomeStrategy : AbstractStrategy

Parameters, signal processing and mostly boilerplate code

No idea why no cs files are generated for you, however if the optimization produces results, it's weird but would it matter that there is corresponding file? Any hints in the logs?

Without inheritance there would be too much redundancy and I can only imagine that metaprogramming would be the only other option then.

[ChazJ]

Well, I found the "cause".

I renamed my virtual class from 'StratBase' to 'BaseStrategy' and now it is producing the CS file. Looks like the NT strategy engine is looking for the string 'strategy' in the class name(s).

(Note: NT only saves the main class, not the virtual class code into the CS file)

Nonetheless, I am still a bit concerned about Kate's statement that this architecture is not supported, and is known to have issues.

@Kate - Would you happen to have a list of the known issues?

[NinjaTrader_Kate]

Hello ChazJ,

Thank you for your reply.

I don't have an available list. However, we would suggest using using a partial class as a different approach to separate your logic. You will have access to all methods and properties of the partial class inside of your main script. You may extend the Strategy or Indicator class in partial classes. All you will have to do is design your other NinjaScripts to access the data from this script. Please see the attached .zip file for a working example.

Please see this publicly available link on partial classes in C#:
https://docs.microsoft.com/en-us/dot...es-and-methods

If we may be of any further assistance, please let us know.

[ChazJ]

Thank you Kate.

Just FYI: I made the naming change a noted above, and the CS file was produced. However, I later ran into an issue that produced the following exception:

Error on executing DB command: System.InvalidOperationException: There was an error reflecting type 'NinjaTrader.NinjaScript.Strategies.MyStrategy'. ---> System.InvalidOperationException: Types 'NinjaTrader.NinjaScript.StrategyBase' and 'NinjaTrader.NinjaScript.Strategies.StrategyBase' both use the XML type name, 'StrategyBase', from namespace ''. Use XML attributes to specify a unique XML name and/or namespace for the type. at System.Xml.Serialization.XmlReflectionImporter.Get TypeMapping(

There is only one class / file named 'StrategyBase' so the reference to 'both use' makes no sense to me. NT is definitely confused.

Noting exactly how MojoJojo named his classes, I renamed the virtual class from 'StrategyBase' to 'BaseStrategy' and the exception went away! Now I am really spooked!

I'll take a look at your suggested approach.

[MojoJojo]

Excellent detective work, I would have never guess that naming convention plays such an important role.

Technically using something like

public partial class Strategy : StrategyBase

could be feasible as long as every strategy will have the same base functionality, but the NinjaScript reference hasn't got much material dedicated to the topic.
So far I've not run into any problems with inheritance out of sheer luck by getting the naming right.