What version of the compiler is NT using?

[ETFVoyageur]

The following line is legal in C# 6.0. Visual Studio 2015 accepts it. Sadly it is not legal in NT. I am surprised -- I thought that NT was using an up to date compiler.

public bool Enable { get; set; } = false;

What are NT's plans to move to C# 6.0?

[NinjaTrader_Brett]

C# 6.0 came out near the tail end of our development and is actually a little tricky to integrate support for that since the compiler is no longer part of .net framework. You have to use the new roslyn compiler now separately. Furthermore various third party tools we use didn't support it yet so we made the decision to hold off on support for that.

There is a workaround which is developing in Visual Studio to compile a .dll and import it into NinjaTrader. I made this template visual studio file which allows you to do just that. As long as NT is installed in default location you can develop in this visual studio project. Press F5 and it will copy over a DLL to NT to autoload and start NinjaTrader in debug mode. The example uses an AddOn but you could do indicators/strategies/other as well.

-Brett

[ETFVoyageur]

Sounds attractive, Brett. I do have one concern -- how will the NT Export function work with this? Export tries to compile what you are exporting, and files developed this way will not compile for Export if they use 6.0 language features. Won't that be a problem?

[NinjaTrader_Brett]

DLL's don't get compiled just 'Referenced'. So should be fine.

[ETFVoyageur]

I do not understand -- what I am referring to is Tools | Export | NinjaScript, which is what Support sometimes asks for. Will that work?

[NinjaTrader_Brett]

Yes it will work. I should let you know that to export that custom assembly you would need to follow these steps on the exporting DLL's.

http://ninjatrader.com/support/helpGuides/nt8/en-us/distribution_procedure.htm

[ETFVoyageur]

Great! Thanks!

[dalebru]

C# 6.0 came out near the tail end of our development and is actually a little tricky to integrate support for that since the compiler is no longer part of .net framework. You have to use the new roslyn compiler now separately. Furthermore various third party tools we use didn't support it yet so we made the decision to hold off on support for that.

There is a workaround which is developing in Visual Studio to compile a .dll and import it into NinjaTrader. I made this template visual studio file which allows you to do just that. As long as NT is installed in default location you can develop in this visual studio project. Press F5 and it will copy over a DLL to NT to autoload and start NinjaTrader in debug mode. The example uses an AddOn but you could do indicators/strategies/other as well.

-Brett

Brett,

Today I finally got a chance to try this technique, and it's really super! Thank you so much.

I would encourage you to "promote" this somehow, including adding it to the Help Guides, perhaps as an "advanced" technique under your Visual Studio section. Maybe with a brief explanation that the NinjaTraderAddon project properties Build Steps has two xcopy commands under Build Steps to copy its dll and pdb files to the proper location, and the NinjaTraderStartupProject project properties Debug has "Start external program" to launch NT8.

This will save those of us who like to "live" in VS a LOT of time!

Thanks again,
Dale

[NinjaTrader_Brett]

Glad to hear, for sure will look to promote it a bit more. We do have a page that talks about this for add ons in our help guide but we could do better job at highlighting.

[ETFVoyageur]

Brett,

Thanks for the VS setup. Very nice.

Whenever I run, I get the following message. Does not seem to cause any problem. Do I have something wrong with my setup, or can I just safely ignore the message?

System.Windows.Data Error: 4 : Cannot find source for binding with reference 'RelativeSource FindAncestor, AncestorType='NinjaTrader.Gui.Tools.NTWindow', AncestorLevel='1''. BindingExpressionno path); DataItem=null; target element is 'InstrumentSelectorPopup' (Name='instrumentSelector'); target property is 'OwnerWindow' (type 'NTWindow')

I have imported the NinjaTrader.Custom project -- that seemed like the best way to do normal development. Works fine once I added xcopy commands. The only odd thing is that whenever I run NT it modifies the NinjaTrader.Custom project and I have to tell VS to ignore that so I can go on debugging. Is there some setting -- perhaps a startup switch to NT -- that will suppress it rewriting the project file?

My only concern is that Tools | Export | NinjaScript will not work if I incorporate any C# 6.0 code, because it will not be able to compile the NinjaScript.

Thanks again for providing this,
EV

[ETFVoyageur]

Dale,

I just discovered this is discussed to some degree in the educational material about developing addons (https://ninjatrader.com/support/help...ng_add_ons.htm), including the following link: Download Visual Studio Solution for AddOn Development

--EV

[NinjaTrader_Brett]

Should be safe to ignore, the visual studio "WYSIWYG" is a problem for us since we have so much dynamic resources (Skins, Languages, etc) and the editor just doesn't work well with that.

No way that I know of to suppress the overwrite of the file. Would just keep my own stuff separate and not branch in the NInjaTrader.Custom solution.

[ETFVoyageur]

Thanks, Brett.

It has been working fine so far. I have just ignored that message. On reloading -- I just ignore that as well, as long as I want to keep on debugging. Otherwise I reload. It does not seem to overwrite my configuration information, so no problem.

As I just noted in another thread, the workflow is nicer now that I am following your suggestion. Furthermore, aside from access to C# 6.0 features, I can also put in breakpoints that will get hit before I would have had time to manually attach to the process.

The only glitch I have noticed is that NT can no longer export NinjaScript -- it gripes because it cannot compile some of my files. I'm not sure what Export does other than zip up a set of files that will compile together. If there is nothing else, I guess I can just manually zip up the equivalent and warn the recipient compilation will have to be done with Visual Studio.

Thanks again for the suggestion.

--EV