Bad generated export code -> Can not import

[TapeReader]

We have a library of indicators that we are in the process of converting to 8.

When we export the library to a protected assembly, everything seems ok as there are no log messages or errors.
However, when we go to import the resulting zip file, the import fails with a message like:

Import failed: The NinjaScript Archive File may contain duplicate method names that already exist on you PC, ....

There are also compile errors in the log indicating: Error compiling import assembly: Name error CS1001: Identifier expected

The issue seems to be a bad template cs file that is generated in the zip file. Parts of the file seem fine, but parts for certain indicators are missing the indicator name. For example:

private OurNameSpace.[] cacheOurNameSpace.; // example from IndicatorRenderBase section

The name of the indicator is missing after the first dot, and should replace the second dot. Similar errors are in the other sections of the template code as well.

I suspect the problem has something to do with how the code is structured.

We use a number of abstract base classes.

Previously, via the Ninja 8 forum, we were told to place this code in the AddOns dir so the code would be properly generated/compiled.

See here: http://ninjatrader.com/support/forum...ad.php?t=77688

This worked, but the export seems to be broken when we use the mechanism.

Please advise.

[NinjaTrader_DaveI]

Thank you for bringing this to our attention. I've tested this process by exporting the indicator & abstract class contained in this forum thread: http://ninjatrader.com/support/forum...d.php?p=426013.

I am able to export and re-import with no issue on my end. Is there any way you can provide an indicator (or strategy, etc.) with an associated abstract class which will reproduce this issue, so that I can test this out on my end?

[TapeReader]

After trying to generate an example, I now have more clarity on the the issue.

For some reason, the generated magic code is not being generated for some of our indicators (about half of our indicators are bad).

Those indicators are the ones that have issues in the generated export template code. Not sure why that code is not being generated.

What is it about an indicator class that causes the magic code to be generated?

Our leaf (non-abstract) classes are very lean and may only have a single method override.

Some seem to generate fine and others do not.

I have not been able to generate a trivial example that shows this behavior.

Is there a way to mark a class as an indicator and force the magic code generation?

[NinjaTrader_DaveI]

Yes, if you cast the class to the Indicator type ("public class myClass : Indicator"), then compile it in the NinjaScript Editor, you should see the code appear. Please let me know if you still see something different.

[TapeReader]

Yes, if I change the base class the magic code appears, but as soon as I change it back to the correct base class the magic code disappears again.

Some of our base classes work, and others do not. There is nothing materially different between the different classes, and all of these worked correctly in NT7 (we have only converted for NT8).

The issue seems to be that NT can not figure out that a class is derived from Indicator.

[koganam]

After trying to generate an example, I now have more clarity on the the issue.

For some reason, the generated magic code is not being generated for some of our indicators (about half of our indicators are bad).

Those indicators are the ones that have issues in the generated export template code. Not sure why that code is not being generated.

What is it about an indicator class that causes the magic code to be generated?

Our leaf (non-abstract) classes are very lean and may only have a single method override.

Some seem to generate fine and others do not.

I have not been able to generate a trivial example that shows this behavior.

Is there a way to mark a class as an indicator and force the magic code generation?

You only get the magic code if you inherit from the Indicator class.

[NinjaTrader_Jesse]

Hello,

Some of our base classes work, and others do not.

Can you export a sample that demonstrates this? It would be best if you can export a sample of just the structure of the files without any of the additional logic included, this would likely help clarify what is happening. If some are working and some are not, this seems that there is some difference between the files, but I would be unable to tell without seeing the code and how it is used.

Please let me know if I may be of additional assistance.

[TapeReader]

Our approach has all of our classes inherit from Indicator.

All of the base classes are abstract classes that inherit from Indicator.

The actual indicators then inherit from our base classes (which also means they are derived from Indicator).

The issue is that many of our classes work just fine, while others do not.

I have recreated the exact structure in dummy classes with no code, and of course they work just fine.

So it seems that there is more to it than just structure.

I have also moved the code to a clean install and have same issues.

I think the best way for you to debug is to get a small copy of offending code, but we would need an alternate method to provide the code to you.

Can you suggest a private method for us to provide you with the code?

[NinjaTrader_Jesse]

Hello,

I would first suggest locating the code causing this to happen before sending this item in. As you said, removing the code and leaving the framework seems to work, so something beyond this is likely the problem regarding the rest of the logic.

It would be beneficial to remove small sections of code until this no longer happens, one you do this verify what was removed is the cause by re adding that section of code and testing further.

Once you locate the section causing this, remove all other code that is not related or not needed, the more simple the example is, the better.

Once a sample is created that demonstrates the problem, you can send the code privately, just email: platform support @ ninjatrader.com and include a link to this post.

Please let me know if I may be of further assistance.

[TapeReader]

We have created the attached code generic code with the source for a simple indicator that does exactly nothing, but does not generate magic code.

The following is the structure:

Namespace: NS - all files are in separate namespace

AddOns:
NSIndicator <- abstract base class that derives from Indicator
NSDerived <- abstract class that derives from NSIndicator

Indicators:
NSIndex <- indicator that derives from NSDerived and hence is an Indicator

[NinjaTrader_Jesse]

Hello,

Thank you for creating the structure sample, I will review this and post back after I have checked into the script further.

I look forward to being of further assistance.

[NinjaTrader_Jesse]

Hello,

I reviewed the file and was able to generate the NS code in the indicator if I use the full namespace rather than just the name of the abstract class.

I have attached the modified version of your example, please note the only change is in the indicator for its inheritance.

Original:
public class NSIndex :NSDerived

Modified:
public class NSIndex : NinjaTrader.NinjaScript.Indicators.NS.NSDerived

Please try this on the scripts that are not currently working and let me know if this is a total resolution or if you are still having issues.

I look forward to being of further assistance.

[TapeReader]

This work around is working for us, although it would be nice for this restriction to be removed in the future.