NT Version (8.1.2.0) import error with a protected compiled assembly

[QuantKey_Bruce]

I was able to install it, but only because I obtained the license key directly from SecureTeam. You will want to be patient. I do not believe simply downloading from the link provided above by NinjaTrader is sufficient - unless they change their process (which would be great, but...) you will need a new license to be issued to you in order to use the new version. Perhaps they will fix that.

[L33TB0Y]

I downloaded 6.9.1.2 yesterday and installed it but when I tried entering my credentials it fails. I haven't tried contacting SecureTeam because it has often taken up to weeks getting a reply in the past.

I contacted them today about it, here is to hoping it doesn't take two months to hear back.

[QuantKey_Bruce]

It won't be two months, but two days or even two weeks is not unheard of. Fortunately, these sorts of adjustments do not have to be done often.

[intelligenttrader]

FYI. I sent Agile a request at 10:30pm EST last night (Tuesday 11/14/23) and had this reply waiting in my inbox this morning. I will test both conditions this week.

"I sent you a new license for v6.9.1.2. V6.9.1.2 is compatible with NT v8.1.2. Note that if you would like to protect add-on and distribute them on NT releases deployed before v8.1.2 you will have to protect those add-ons using Agile.net v6.6."

[QuantKey_Bruce]

FYI. I sent Agile a request at 10:30pm EST last night (Tuesday 11/14/23) and had this reply waiting in my inbox this morning. I will test both conditions this week.

"I sent you a new license for v6.9.1.2. V6.9.1.2 is compatible with NT v8.1.2. Note that if you would like to protect add-on and distribute them on NT releases deployed before v8.1.2 you will have to protect those add-ons using Agile.net v6.6."â

intelligenttrader This appears to contradict what NinjaTrader had stated in another thread - that they recommend protecting using the older 6.6 until there is a fix available because the 6.6 would work for 8.1.1.7 as well as 8.1.2.0. If this is statement is to be taken literally, 6.9.1.2 cannot be used to protect assemblies for use on 8.1.1.7...

[sidlercom80]

I tried to use agile 6.9.1.2 with NT 8.1.2.0. That works, I can create a protected assembly without any problems, but unfortunately this cannot be used for older versions. So either the user uses the new NT version from 8.1.2.0 or everything stays the same and therefore all the effort involved in switching to CSharp 8 is absolutely for the cat. what a joke, unfortunately I have no words for it...
​

[QuantKey_Bruce]

NinjaTrader_ChelseaB Please chime in here if you would. This is not the expected situation. If we update to Agile 6.9.1.2 we can make protected assemblies on NT 8.1.2.0 but they don't work on previous NT versions. Yet, if we do not update and stay with Agile.NET 6.6 on NT 8.1.1.7 we can make protected assemblies that work on all versions. We cannot install both versions of NT on the same machine, nor we can install both versions of Agile.NET on the same machine. Creating two different deliverables (one for 8.1.1.7 and down and one for 8.1.2.0 and up) is a support hassle that is not worth it for most. This implies that all or almost all commercial development must stay on 8.1.1.7 indefinitely until this is resolved. What am I missing here?

[L33TB0Y]

FYI. I sent Agile a request at 10:30pm EST last night (Tuesday 11/14/23) and had this reply waiting in my inbox this morning. I will test both conditions this week.

"I sent you a new license for v6.9.1.2. V6.9.1.2 is compatible with NT v8.1.2. Note that if you would like to protect add-on and distribute them on NT releases deployed before v8.1.2 you will have to protect those add-ons using Agile.net v6.6."

They responded to me in a couple of hours as well so it looks like they've dedicated some resources to sorting this out which is great!

[jeronymite]

QuantKey_Bruce makes good points, as usual. One point I would add is that I already am "forced" to have two separate releases streams for my software because of 8.1 and 8.0. The reason is actually relatively "minor" and easily rectified by NinjaTrader, but for my clients, it's an important aspect:

• In 8.0, one could check NinjaTrader.Cbi.License.MachineId, and also check NinjaTrader.Cbi.License.LicensedFeatures for NinjaTrader.Cbi.LicensedFeature.LiveTrading
• In 8.1, both were (initially) removed with the introduction of NinjaTrader.Cbi.UserEntitlement, although subsequently, NinjaTrader.Cbi.UserEntitlement.MachineId was reintroduced; but the ability to check for LiveTrading was not

This ability to check for LiveTrading enables one to see if the user has a live "licence" (as it was in 8.0) or a UserEntitlement to trade live (as it would be in 8.1). It allows relevant helpful checks prior to trade placements that can prevent attempts to trade a live brokerage account when there is no "entitlement" to do so in NinjaTrader, or if for some reason, that entitlement is not active.

If NinjaTrader would make it possible to make such a LiveTrading check in 8.1, that at least would remove the current reason I have for separate release streams. If there is already a way around this, I would like to know it.

Of course, the Agile.NET fiasco is a far more significant matter and deserves absolute prioritisation! Split release streams must be avoided. It's a nonsense for any reason!

Thanks.

[QuantKey_Bruce]

The plot has thickened slightly in that I am being told by SecureTeam that my much more expensive Commercial Edition version can protect assemblies both before and after 8.1.2.0 but my less expensive NinjaTrader Edition has to have two different computers to do it (one running 6.6 and one running 6.9). I'm working to clarify these issues but this has been a bit of a mess. I have not yet personally tested to see if this is true but plan to do so soon.

I want to express, I am still grateful to NinjaTrader for making the investment to get us up to C# 8.0 even with this speed bump. It is hard to make an omelet without breaking some eggs, as they say, and I am confident these issues will be worked out and these are just some minor growing pains. While we all wish this was caught before release (and I'm sure no one wishes this more than NinjaTrader) the last thing I want to do is to give the impression that what we want is for time to stand still in order to assure that we don't break any legacy functionalities. We want and need the NinjaTrader Desktop platform to continue to press forward, and if some minor situations like this present a bit of inconvenience or delay or mean we need to stay on an older version for a month or two while things are worked out, reluctantly, so be it. Let's just get it fixed, and thank you again for getting us up to C# 8.0 Roslyn.

[QuantKey_Bruce]

QuantKey_Bruce makes good points, as usual. One point I would add is that I already am "forced" to have two separate releases streams for my software because of 8.1 and 8.0. The reason is actually relatively "minor" and easily rectified by NinjaTrader, but for my clients, it's an important aspect:

• In 8.0, one could check NinjaTrader.Cbi.License.MachineId, and also check NinjaTrader.Cbi.License.LicensedFeatures for NinjaTrader.Cbi.LicensedFeature.LiveTrading
• In 8.1, both were (initially) removed with the introduction of NinjaTrader.Cbi.UserEntitlement, although subsequently, NinjaTrader.Cbi.UserEntitlement.MachineId was reintroduced; but the ability to check for LiveTrading was not

This ability to check for LiveTrading enables one to see if the user has a live "licence" (as it was in 8.0) or a UserEntitlement to trade live (as it would be in 8.1). It allows relevant helpful checks prior to trade placements that can prevent attempts to trade a live brokerage account when there is no "entitlement" to do so in NinjaTrader, or if for some reason, that entitlement is not active.

If NinjaTrader would make it possible to make such a LiveTrading check in 8.1, that at least would remove the current reason I have for separate release streams. If there is already a way around this, I would like to know it.

Of course, the Agile.NET fiasco is a far more significant matter and deserves absolute prioritisation! Split release streams must be avoided. It's a nonsense for any reason!

Thanks.

I would just add to this that they actually put back NinjaTrader.Cbi.License.MachineId, so you can check that in both 8.0 and 8.1 if you wish. That is what I would recommend that you do, for compatibility reasons. Maybe you can use a proxy measure to determine if it's a live trading account rather than checking the entitlement, although I would absolutely support them opening that up as a public property so we can just read the boolean (again). I would imagine what you really want to know is if the account is a live one, rather than whether the license is a live one, but I could be mistaken.

[NinjaTrader_ChelseaB]

Hello Community,

8.1.2.0 has been upgraded to use the Rosyln compiler to update C# to 8.0. Because of this, a new release of Agile is required to work with this new compiler.

With 8.1.2.0, Agile 6.1.9.2 must be installed.
With 8.1.1.7 or previous, Agile 6.6.0.35 must be installed.

Our development is expecting scripts exported with 8.1.2.0 and Agile 6.1.9.2 to import into 8.1.1.7 and 8.0.28.0.
Also, they are expecting scripts exported with 8.1.1.7 or previous with Agile 6.6.0.35 to import into 8.1.2.0.

The download for 6.1.9.2 and 6.6.0.35 have been made available in the help guide. (It will be necessary to contact Agile to obtain a license key)

https://ninjatrader.com/support/helpGuides/nt8/protection_dll_security.htm

[QuantKey_Bruce]

Our development is expecting scripts exported with 8.1.2.0 and Agile 6.1.9.2 to import into 8.1.1.7 and 8.0.28.0.

NinjaTrader_ChelseaB Thank you for chiming in here! But, this one part, specifically, does not appear to be true, and also, directly contradicts what SecureTeam is telling us. Are you certain? Have you tried this? Importantly, when you test, you must use the NinjaTrader Edition not the Commercial Edition that development is using to protect the platform itself. According to SecureTeam, the NinjaTrader Edition is not the same in this regard. I could be misunderstanding, but I do not think that I am. Also, several users above have confirmed that they were unable to import scripts exported from 8.1.2.0 with Agile 6.1.9.2 into NT 8.1.1.7. Lastly, in the help guide, it says to use 6.6.0.35 for 8.0.28.0 but leaves out that you must use 6.6.0.35 for 8.1.1.7 because 6.1.9.2 is not compatible according to SecureTeam. Could you please confirm these facts? Hopefully, I am misunderstanding. If you are correct, that would be great.

[sidlercom80]

The left hand doesn't know what the right hand is doing, that's exactly how it looks to me.

[bltdavid]

If NinjaTrader would make it possible to make such a LiveTrading check in 8.1, that at least would remove the current reason I have for separate release streams. If there is already a way around this, I would like to know it.

Isn't this satisfied by checking the account name?

I mean, if any account name begins with any form of
'Sim' (uppercase or lowercase, or any combination),
then it's a simulation account -- otherwise you can
treat it as a live account, right?

Are you just trying catch 'demo' vs 'live' accounts?

Why is the distinction of what 'LiveTrading' provdes
so important to your product?

Not trying to be a troll, just really curious how and
why 'LiveTrading' has come to matter so much.

The fact that you have bifurcated your own product
releases based upon availability of 'LiveTrading',
that's a serious engineering decision which I know
you wouldn't agree to lightly -- thus you really got
my eyebrows raised.

Why plant a flag on 'LiveTrading', so to speak?

What exactly does 'LiveTrading' provide that the
'Sim' prefix check doesn't provide, and why is that
difference such important feature for your product?