Indicator cannot be serialized, ONLY after exporting

[neoikon]

I have some old NT7 indicators that haven't changed in years, but now when I export them (encrypted), then import them on another machine I get serialization errors when saving the workspace.

They work fine locally (which is running the source code).

The indicators import successfully on another machine and they run fine on a chart. However, if I save the workspace or try to create a chart template, I get serialization errors.

Exported on 7.40, imported into 7.41

Again, these worked fine for years. Is there any way of determining which param is causing the issue? Or any other technique in determining what is the issue?

Also, in the Trace file I'm seeing "System.IO.FileLoadException: AssemblyResolveEvent handlers cannot return Assemblies loaded for reflection only." Could that be a root issue of something?

Thank you

EDIT: I re-exported in 7.42 and now I can't import due to "duplicate method names" error even after removing everything and restarting. NinjaTrader is SO incredibly fragile! So, now I'm stuck.

[NinjaTrader_ChelseaB]

Hello neoikon,

Currently, NinjaTrader 7 is no longer under active development. If you are on NinjaTrader 7, I highly recommend moving to NinjaTrader 8 before NinjaTrader 7 reaches its end of life.
Updates to NinjaTrader will contain the latest security updates and bug fixes, as well as new instruments and rollover dates.


While serialization errors are usually related to public variables that are not using the XmlIgnore() attribute, It might be something in the script itself. The error notes something using reflection.

https://ninjatrader.com/support/helpGuides/nt7/user_definable_color_inputs.htm

http://www.ninjatrader.com/support/forum/showpost.php?p=124724

Please create a simple demonstration script, or reduce the script to remove everything that is not related to reproducing the error and provide the open source export of demonstration script so that we can test.

To export a NinjaTrader 7 NinjaScript so this may be shared and imported by the recipient do the following:

1. Click File -> Utilities -> Export NinjaScript
2. Enter a unique name for the file in the value for 'File name:'
3. Select the strategy from the objects list on the left -> click the right facing arrow ">" to add the strategy to the export
4. Click the 'Export' button -> click 'yes' to add any referenced indicators to the export -> click OK to clear the export location message

The exported file will be in the following location:

• (My) Documents\NinjaTrader 7\bin\Custom\ExportNinjaScript\<export_file_name.z ip>

Below is a link to the help guide on Exporting NinjaScripts.
http://www.ninjatrader.com/support/h...nt7/export.htm

Once exported, please attach the file as an attachment to your reply.

[neoikon]

I want nothing more than to ditch NT7. But I have customers that still use it.

Again, the script works fine locally. It only breaks after exporting. So, strip it down to what that is causing the issue?

EDIT: I re-exported in 7.42 and now I can't import due to "duplicate method names" error even after removing everything and restarting. NinjaTrader is SO incredibly fragile! So, now I'm stuck.

[NinjaTrader_ChelseaB]

Hello neoikon,

Is the open source version of the script still in NinjaTrader?

Are there other files that are using class names that are in this file?

[bltdavid]

I've seen successfully exported zip files fail to import due to a
public property based upon an internal public enum that was not
fully qualified with its complete namespace.

That is,

public MyEnum MyValue
{
...
}

needed to be,

public [I][COLOR=#e74c3c]<fully[B].[/B]qualified[B].[/B]namespace>[B].[/B][/COLOR][/I]MyEnum MyValue
{
...
}

Once MyEnum was fully qualified, the import worked.

I never had a problem with NinjaScript supplied enums, so I never
fully qualify those.

It was only new public enums defined specifically by an indicator
or strategy.

Properties using those enums needed a fully qualified namespace
to avoid the import problem.

Being 'public' wasn't enough, the enum also needed to be fully
qualified when used in a property type -- even if the namespace
was previously declared with a 'using' directive.

Just fyi.