I am a hobbiest trader / developer currently publishing indicators for Quantower and TradingView, with an emphasis on and enthusiasm for producing public domain code.
I have done some work with NinjaTrader 8, and would like to do more, however the lack of full and coherent integration with Visual Studio has created several headaches that I would like to address.
After extensive research on how NinjaTrader works in tandem with the build system, file system locking, and it's own application lifecycle / integrity concerns, I have come to the conclusion that the best solution, for all parties, would be for NinjaTrader to receive a command from an external source to trigger a rebuild of the Custom folder and relink/reload the relevant dlls, as happens when using the compile button in NinjaScript Editor.
If this feature already exists, please excuse my ignorance, but I believe, from my research, it is not yet available. It is my hope that it will be supported in the future.
I understand that you do not intend to fully support Visual Studio development, and I feel I understand your reasoning, but the only true roadblock I can find to doing it myself is that NinjaTrader only releases control over the relevant dlls when you trigger recompilation inside the NinjaScript editor.
This means that external redeploys can only be managed by rebooting the entire NT application, or "forced finger automation" (i.e. triggering an arbitrary recompile inside the NinjaScript Editor).
As stated above, my request is thus: that NT allows for a request to trigger it's own recompilation / relinking process, as would happen when using the NSE compile button.
I realize that live debugging from Visual Studio would require it to manage the startup of NT or setting up a debugging communication port, and I am not requesting such accommodation with this feature. I am only requesting that NT "play nice" with file system changes by providing a method to engage it's own process, already in use internally, without having to use the graphical interface.​
​
Proposed Method:​
One way to do this would be to watch for a specific file (i.e. ".recompile") and then delete the file when the process is complete. This would probably be the easiest for independent developers to work with, and for NT to implement.
Another acceptable solution would be to listen on a port for well formed requests and respond with a success/fail message. This would be slightly more complicated, but technically sound, and would lay the groundwork for externalizing live debugging without application restart.
Background on my research / experience:
So far I have developed 2 different NT8 indicators, which I have compiled, edited, and published using the embedded tools inside NT8 (NinjaScript Editor and export options).
I found these tools sufficient for a basic startup project, but awkward and insufficient for detailed development or rapid iteration.
I had already developed a series of MSBuild inheritable tasks for Quantower to address similar problems, so I set out to apply these kinds of tools for NinjaTrader as well. I have not provided links to such examples in case it is a forum terms violation (I haven't checked).
When attempting to open the projects in VS2022, in order to research build automation and automatic packaging, I started by using the VS button in NinjaScript Editor, I almost immediately broke compilation back inside NinjaTrader, because of the issue of generating duplicate assembly info files.
I was able to fix the problem, and proceeded to research the root cause and solutions.
Based on my experience with updating other projects to modern standards, and subsequent testing in this cases, I assert this is because the system generates legacy style "DotNet Framework" project files, when the poorly documented, but simpler and more flexible / feature rich "DotNet Core" project files would solve the problem. Cleaner "Framework" solutions are provided with the "Add-On" project template example, but those generated by NSE/VS experience are the least desirable and do not play nice with VS2022.
I spent at least two full "workdays" testing modernized project file output, monitoring the file system access, catching temporary files before deletion (to verify NT internal compilation commands), making changes inside and outside of NinjaTrader, reading dozens of support posts, and comparing the results to my experience with Quantower. I have also reviewed multiple examples of packaging NinjaTrader extensions, from published examples and it's own output, verified the enabling newer CSharp language features, generated proof of concept for automated packaging, and tested several approaches to automated deployment of add-ons. I have broken / fixed / rebooted my NT install countless times.
It is my view that NT support is very respectful, active, and honest, and I understand how organizational and development logistics have placed this issue between customer desire and practical company concerns. I believe the platform is overall technically sound, albeit weighted with technical debt, and exists in a market space where it could benefit from modernizing this process.
I hope that by meeting in the middle with the solutions proposed that the company and the community can work together to provide practical solutions to modernized NT development practices, without placing undo burden on the company's technical staff.
Thank you for your consideration.
Comment