On this page
Key terms for this guide
These glossary pages cover the ideas and platform language most closely tied to this workflow.
Start with the exact platform version
NinjaTrader 7 and NinjaTrader 8 packages are not interchangeable. If an import fails, confirm that the ZIP was built for the version you are running before changing anything else.
- A package built for NT7 should be treated as a legacy file until a native NT8 version exists.
- Matching the exact platform family is more important than tweaking settings after the fact.
- Start with version sanity before assuming the indicator code is broken.
Use a clean chart to isolate the problem
After import, open a new default chart and add only the new indicator. If it works there, the issue is more likely a workspace, template, session, or data configuration problem.
- A clean chart removes template clutter from the test.
- If the indicator works on the clean chart, the import itself probably succeeded.
- That usually points to a chart setup issue instead of a package issue.
Check custom assemblies carefully
Duplicate or older custom assemblies can create compile errors that appear unrelated to the indicator you just installed. Remove or update conflicting packages only after backing up your platform files.
- A compile line in one file can still be triggered by a conflict somewhere else in Custom.
- Older copies of the same indicator family can cause ambiguous references.
- Backing up first keeps troubleshooting from becoming a recovery project.
Frequently asked questions
What should I save when a NinjaTrader import fails?
Save the exact error text, file path, and line number. Those details are usually what makes the problem diagnosable.
Does an import error always mean the indicator itself is bad?
No. Version mismatch, conflicting custom assemblies, session/template issues, and workspace state can all cause errors that look like indicator failures.