8.1.3.0 crashes on Attach to Process in Visual Studio 2022

[Juanma85]

Thank you for your answers NinjaTrader_ChelseaB and QuantKey_Bruce

I'm new to this so bear with me a bit more. I've already removed 5 assemblies that I had installed and my platform is still crashing when I attempt "attaching to Process" in Visual Studio 2022.
I couldn't figure out how to their Agile.NET version, but I did see that some of them came with an info.xml that said version 8.1.1.x, so I removed them.

Now, there are 3 assemblies in the remaining set that I'm sure I installed. For all of them, the info.xml says version 8.1.2.1 so, according to my understanding, those should not be causing the crash. Can you please confirm?

There are a few other assemblies on the list but, as far as I can tell, they came with NT8, so I shouldn't remove them. I googled extensively and couldn't find a list of default assemblies that NT8 comes with. Also, for the remaining assemblies (excluding the 3 I mentioned), I couldn't find the corresponding DLL or an info.xml anywhere in the file system, so that makes me think that they're indeed default assemblies.

Can either of you help me confirm/refute which of the remaining assemblies come with NT8 and thus, should not be removed? (Please see attachment). I'm trying to see if I should try removing some of them and see if I can finally avoid the crash.

Note: AdvancedRiskReward_BurnoMeza, BM_PRO and GestorEmocional are the 3 assemblies that I know I installed but their info.xml says version 8.1.2.1

[QuantKey_Bruce]

Why don't you just rename your Documents -> NinjaTrader 8 directory and then do a clean install of NinjaTrader so you can do what you need to do here? That will also help you answer your own question about what comes with NinjaTrader. When you're done, you can simply rename the Documents -> NinjaTrader 8 directory back. As a matter of principle, if you're doing development work or exporting assemblies yourself, you should have as few compiled assemblies installed as possible because the more is in the mix, the more confusing it will become. You CAN do development work with a dozen assemblies installed if it's all a careful arrangement, but you shouldn't start out that way, especially if you're not sure what you're doing, and it's far better to start simple and slowly and carefully build up where you know exactly what you've done at each stage than to start with a dozen things and ask the forum what to do.

[DerkWehler]

Hello Juanma85,

I just want to confirm QuantKey_Bruce is correct in post #14.

I would like to start (i.e. learn) to use VS with NT because I don't much like the editor / 'development environment', but for me, it's definitely not worth uninstalling things or keeping separate versions of installs somehow, especially when NT does not make that easy.

So hopefully this may be a fix that actually is important enough that they do something about it. If it is ever fixed, is there some way of being notified?

[NinjaTrader_ChelseaB]

Hello DerkWehler,

As far as assemblies obfuscated with Agile 6.6.0.35 and previous causing crashing when attaching the debugger process in visual studio, unfortunately from my understanding this is not something that can be fixed.

You will need to obtain new exports of these assemblies exported from NinjaTrader 8.1.4.1 and obfuscated with Agile 6.9.1.2 or later, and this would resolve the crashing.

When new releases have bug corrections or new features, this is listed in the release notes in the help guide.

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

[Zinovate]

I am chasing these same issues yet again.
It sounds like this will be a continual effort to get vendors to update their indicators if you develop against them.

What is the best path forward, develop only against 8.1.3.1?

I already have a vendor that has given up on providing continual updates due to these issues.
If what Bruce is saying is correct, that really limits my ability to build ontop of other indicators, especially in strategies. Honestly, that was a strong point in the Ninja ecosystem.

[NinjaTrader_ChelseaB]

Hello Zinovate,

You can choose to use the NinjaScript Editor and Visual Studio to continue developing.

The only issue is the attach debugger crashes Visual Studio so that one functionality will be missing. You can still use prints to debug.

https://support.ninjatrader.com/s/article/Developer-Guide-Debugging-using-Print-and-TraceOrders

The best path forward is for everyone to update to the latest release (currently 8.1.4.1), and for vendors to create new exports with the new release of Agile if they want their customers to be able to continue using the attach debugger to process functionality. Agile came out with a new release with new security which is what makes this change necessary and all vendors should be re-exporting with this new security.

[Zinovate]

How can you develop without debugger access?. That is not a realistic option. Many times the debugger is required because the docs have gaps as all developer docs do. Debugging is a must if NT is a viable option.
sadly your vendors like WealthCharts/become a better trader refuse to issue updates. I wish Ninja trader did more to help with this but all it takes is one vendor and your system is not viable

[NinjaTrader_ChelseaB]

Hello Zinovate,

I'm not quite understanding how attaching the debugger to the NinjaTrader process fills in gaps from the developer documentation.
Scripts can still be edited in Visual Studio without attaching the debugger to a live process.
As far as I know this does not affect Visual Studio Intellisense when the debugger is not attached to the process.

That said, you can debug by adding prints in the code.

From time to time there will be new technology that requires vendors to update scripts. This is similar to how application and hardware developers need to make new releases for new versions of Microsoft windows. In this sense, if the vendor does not update, the script may not be usable in newer releases and may be vulnerable to security flaws in old releases.
In the cases where the vendor is refusing to update, this may mean that the assembly becomes out dated and should no longer be used and should be removed from NinjaTrader.

[Zinovate]

I assume you're not a developer.
Being able to attach a debugger is vital in any development effort, no matter how good or bad the documentation is; that is simply a fact of developing.
You have to be able to set a breakpoint, investigate the data structures, and validate that your code is working right.
This is even more important because you simply cannot unit-test Ninjatrader indicators.

I would implore you to ask your internal development team if they could develop Ninja Trader itself without using a debugger. I really implore you to do that and then respond.
I promise you that your team would never attempt to build Ninjatrader without a debugger.

I would actually ask the other developers on this if they feel that they can / should develop without a debugger????

Also using "PRINT" statements in code to debug is not very legitimate. That's like moving back to coding in 1995.
Your statement about requiring updates is actually not the case for the most part. MS works hard to ensure compatibility. Forced upgrades is not the norm. I hope this isn't an ongoing thing and you can work the issue out with Agile.NET going forward.
I hope every version upgrade doesn't require all new DLLs from all vendors

[NinjaTrader_ChelseaB]

Hello Zinovate,

Unfortunately, as this was a change to Agile from the SecureTeam due to security this was required by NinjaTrader and is an unfortunate affect.
There was not a choice in the matter.

You could choose to not use those assemblies as suggested in post # 23.
You could choose to not update and be vulnerable to security flaws as well as not being able to use assemblies exported in later versions with the debugger.
You can ask the vendors to not use Agile and leave the scripts vulnerable to deobfuscation but I doubt many would be willing.

Our developers do not develop with 3rd party vendor assemblies installed and do not have this issue.
If there were testing with a 3rd party assembly vendor it would be required for the vendor to export using the latest release as previous releases have no further development.

Going forward if Agile make a new release with a new compiler (in this case a change to rosyln to support C# 8 by popular request) I imagine it will also require developers to re-export scripts for the new technology. I'll put in a feature request on your behalf, but this doesn't sound feasible.

[Zinovate]

There isn't anything that can be done really. The Agile.NET change is the breaking point. It's too bad that your internal team doesn't work with any 3rd party indicators, that might have found this issue earlier and would have helped provide clearer guidance from the start.

From a business standpoint, it makes me realize that any strategy that is built on 3rd party indicators, you're putting yourself at risk in this situation. This is a really big deal to be honest.

Sadly, I have vendors that refuse to address any Ninjatrader-related issues. Why, you'd have to ask them.

Is there any way to tell if an indicator is compatible with the Agile.NET change?

There are a lot of 3rd party indicators on the Ninja Ecosystem site built by this wonderful community.
I assume that if you can't tell and you are trying to use any of those indicators, you are going to have to try them 1 by one and launch the debugger to ensure compatibility.

I've basically had to spin up an entire development-only laptop just because of this issue. In my trading, I use 3rd party indicators, so this issue complicates being a NT developer in a really big way. I've had to rethink my entire setup.

The development ecosystem around Ninjatrader is one of it's more unique features and this really makes things harder.

[NinjaTrader_ChelseaB]

Hello Zinovate,

In the export .zip file there will be a info.xml file.
If the <Agile> tag does not show 6.9.1.2 (or None) it is not compatible with the latest release.

[grose]

Hello mfabache,

Welcome to the NinjaTrader forums!

This is correct. If you are not able to obtain an export created with 8.1.2.X or later, it would be necessary to downgrade to 8.1.1.7.


caryc123,

I've made sure our vendor support team is notified about this and would be able to provide direction for vendors.

Hi Chelsea and Team,

It's clear from this thread you can't use VS 2022 to debug NinjaScript if you have libraries that were obfuscated using Agile.Net 6.6.0.35. What's not clear is, can you use VS 2019 in that case? VS 2019 is one of the versions generally supported.

Thanks,

Gordon

[NinjaTrader_ChelseaB]

Hello Gordon,

From my understanding, the version of Visual Studio is not the issue. The issue is attempting to attach a debugger to the running process with scripts compiled with two different compilers.

I do not expect Visual Studio 2019 to work either. You are certainly free to give it a try.