Nasty error after binding new DLL

[molecool]

I have a very simple DLL that's compiled for .Net 3.5 (via SharpDevelop 3.2). It's one class with some enums - it's a dumb placeholder nothing else. I have bound DLL files into Ninja before and there has never been any trouble. I am unable to launch Ninja with the DLL inside the bin/Custom folder as it crashes before opening anything. These are the details in the error panel:

Problem signature:
Problem Event Name: CLR20r3
Problem Signature 01: ninjatrader.exe
Problem Signature 02: 7.0.1000.14
Problem Signature 03: 51b61428
Problem Signature 04: NinjaTrader.Core
Problem Signature 05: 7.0.1000.14
Problem Signature 06: 51b61447
Problem Signature 07: 2da9
Problem Signature 08: 0
Problem Signature 09: System.ArgumentException
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033

I then remove the DLL in order to launch Ninja successfully. Then I copy the DLL back in the Custom folder and open a source file in Ninja to perform the compile. The compile completes fine and I have to actually launch a chart and try to add the strategy or indicator in order to get the following error message:



I'm also getting this:



And a host of unrelated errors:



None of these were shown before I attempted to bind in the DLL. Again, this is something I have done in the past and with DLLs containing a lot more source than this.

That's pretty scary and I'm not sure what to do here. Any help would be most welcome.

[molecool]

Fyi

The only pertinent thread I found was this:

http://www.ninjatrader.com/support/forum/showthread.php?t=47205

I verified that the project is being compiled as .Net 3.5 - but I get these error messages and crashes

[NinjaTrader_PatrickH]

Hello molecool,

Thank you for your post.

Creating assemblies outside of NinjaTrader for use in NinjaTrader is not supported. From the errors I would think the strings used in this assembly are causing this error, quite possibly even the enums.

To debug this you could remove the assembly from NinjaTrader and use the same code from your assembly (or a similar alteration) in an indicator to see if the code compiles in NinjaTrader.

[molecool]

Hello molecool,

Thank you for your post.

Creating assemblies outside of NinjaTrader for use in NinjaTrader is not supported. From the errors I would think the strings used in this assembly are causing this error, quite possibly even the enums.

To debug this you could remove the assembly from NinjaTrader and use the same code from your assembly (or a similar alteration) in an indicator to see if the code compiles in NinjaTrader.

Hi Patrick - well, the purpose of my exercise was to externalize those enums into one external file. They all used to be in an indicator file and I didn't want to pollute the global namespace.

Again, I have done this many times before - why would something so simple start throwing errors?

[molecool]

Not a fix but I know what's happening

I just removed the enums in the DLL and just left an empty class construct. It works in NinjaTrader as long as there are no enums defined. As soon as I add a single enum and import the new DLL into Ninja all hell breaks loose.

So I have to hand this over to you guys. I know it's not officially supported but if you guys could give me a hint why NT7 pukes on enums in a DLL I would be very grateful. I can work around it by using a faux indicator but it's ugly and I would prefer to be a good boy and externalize certain definitions and enums into a bound DLL. Again, I didn't do anything special - you can easily try it yourself by creating a simple class file and then do this:

namespace Foo {
  public enum Def {
     OptionA,
     OptionB,
  }
]

Any pointers/help appreciated.

[koganam]

I just removed the enums in the DLL and just left an empty class construct. It works in NinjaTrader as long as there are no enums defined. As soon as I add a single enum and import the new DLL into Ninja all hell breaks loose.

So I have to hand this over to you guys. I know it's not officially supported but if you guys could give me a hint why NT7 pukes on enums in a DLL I would be very grateful. I can work around it by using a faux indicator but it's ugly and I would prefer to be a good boy and externalize certain definitions and enums into DLL.

Any pointers/help appreciated.

The correct place to define new object types is in a namespace. In what namespace have you defined the enums in your dll?

[molecool]

The correct place to define new object types is in a namespace. In what namespace have you defined the enums in your dll?

YES, that was my understanding and of course best practices. Here's what I did:

using System;
using System.Collections.Generic;

namespace DataTypes
{
	
	public enum MAType {
			SMA, 
			EMA, 
			HMA
       }

	/// <summary>
	/// Holder class for data types.
	/// </summary>
	public class DataTypes
	{
		
	}
}

Try it out - it'll blow it up. The only way to launch Ninja afterward is to remove that DLL out of your Custom folder.

[koganam]

YES, that was my understanding and of course best practices. Here's what I did:

using System;
using System.Collections.Generic;
 
namespace DataTypes
{
 
    public enum MAType {
            SMA, 
            EMA, 
            HMA
       }
 
    /// <summary>
    /// Holder class for data types.
    /// </summary>
    public class DataTypes
    {
 
    }
}

Try it out - it'll blow it up. The only way to launch Ninja afterward is to remove that DLL out of your Custom folder.

2 matters of note..

1. You have defined this as a class, but you are missing many of the namespaces that would need to be used by any class to which you bind this one. Reflection will be a problem.
2. You have a defined namespace anyway. Why not just have a "using" statement for the namespace directly whenever a class needs it, and ditch the dll whole binding issue. (i.e., remove that class definition and simply use the namespace: there is nothing in the class anyway).

[molecool]

2 matters of note..

1. You have defined this as a class, but you are missing many of the namespaces that would need to be used by any class to which you bind this one. Reflection will be a problem.
2. You have a defined namespace anyway. Why not just have a "using" statement for the namespace directly whenever a class needs it, and ditch the dll whole binding issue. (i.e., remove that class definition and simply use the namespace: there is nothig in the class anyway).

I think I'm losing you on both counts, mate:

1. What namespaces am I missing? In Java (which is my orignal background) I would simply create a package and an abstract holder class. Namespaces frankly confuse me a little and to my mind it's just a matter of structuring things (i.e. C# style packaging). In any case I'm missing what other namespaces I would need to bind in.
2. I am using a 'using' statement in all the classes (i.e. 'using DataTypes') that make use of this enum. This way I have it in one place and that was the idea. Maybe I'm missing your point...

[koganam]

I think I'm losing you on both counts, mate:

1. What namespaces am I missing? In Java (which is my orignal background) I would simply create a package and an abstract holder class. Namespaces frankly confuse me a little and to my mind it's just a matter of structuring things (i.e. C# style packaging). In any case I'm missing what other namespaces I would need to bind in.
2. I am using a 'using' statement in all the classes (i.e. 'using DataTypes') that make use of this enum. This way I have it in one place and that was the idea. Maybe I'm missing your point...

C# was designed by the same person who designed Java. He took the opportunity to simplify quite a few of the complexities that were really not necessary. C# namespaces are simply used, unlike in Java where they must be packaged.

This is being made more complex than necessary. You have defined the namespace; you have populated it with the object prototype; you are "using" the namespace in the class that needs it. That is all that is needed.

• Lose the definition of the class in that file, and have the namespace.
• Call the namespace when you need it.
• There is no need to bind anything.

It really is that simple, and it is much simpler than the Java need to bind an abstract class.

[molecool]

C# was designed by the same person who designed Java. He took the opportunity to simplify quite a few of the complexities that were really not necessary. C# namespaces are simply used, unlike in Java where they must be packaged.

This is being made more complex than necessary. You have defined the namespace; you have populated it with the object prototype; you are "using" the namespace in the class that needs it. That is all that is needed.

• Lose the definition of the class in that file, and have the namespace.
• Call the namespace when you need it.
• There is no need to bind anything.

It really is that simple, and it is much simpler than the Java need to bind an abstract class.

Well that is something new to me. I wasn't aware that I could simply create a file with just a namespace in it. The Java compiler (or interpreter) would have balked at that. But I suspect that this won't fix the issue at hand, i.e. Ninja blowing up via the error described below. I'll try it and report back.

[molecool]

[*]Call the namespace when you need it.[*]There is no need to bind anything.[/LIST]It really is that simple, and it is much simpler than the Java need to bind an abstract class.

What do you mean by 'call the namespace when I need it'? Are you referring to the 'using' statement? Or is there another way to refer to a namespace? Can you be more specific and perhaps provide an example? Thanks.

[koganam]

What do you mean by 'call the namespace when I need it'? Are you referring to the 'using' statement? Or is there another way to refer to a namespace? Can you be more specific and perhaps provide an example? Thanks.

Here is the example I provided on one of the many times this came up for discussion on this forum. http://www.ninjatrader.com/support/f...d.php?p=216047

You might want to read the whole rather long thread, as it has many other fine points of discussion about namespaces, clashes and how to ensure that an export that contains a custom namespace is viable.

ref: http://www.ninjatrader.com/support/f...d.php?p=215996

[molecool]

Concrete solution desired

Here is the example I provided on one of the many times this came up for discussion on this forum. http://www.ninjatrader.com/support/f...d.php?p=216047

You might want to read the whole rather long thread, as it has many other fine points of discussion about namespaces, clashes and how to ensure that an export that contains a custom namespace is viable.

ref: http://www.ninjatrader.com/support/f...d.php?p=215996

Read the thread - thanks, but nothing new in there that I wasn't already aware of. Having coded in OOP for two decades my original confusion was one purely based on not fully understanding C# namespaces (and foolishly following NinjaTrader's recommendation of placing enums into the global namespace), which now has been remedied. My bad - we're moving on.

I am still unclear however as to why NinjaTrader would reject a clearly defined namespace with our without a class stump (abstract or otherwise) in the containing resource. In the meantime I have resorted to replicating the same stump class which inherits from NinjaTrader.Indicator. Not my favorite thing to do but I'm not willing to devote more time to figuring this out as I believe it has to do with how NT handles enum definitions in DLLs. There's apparently a bug in there but since it's not 'supported' I think we architectural purists are without a paddle on this one ;-)

Incidentally the example you provided is what I'm doing right now. However, should I ever export any indicator/strategy that uses that particular enum then I will have to include that indicator as well. My MAType was a good example of that - it's being used across several of my indicators/strategies and it would have been preferably to simply attach a DLL that had been compiled outside of NinjaTrader instead of having to include the stump indicator that contains them.

[koganam]

Read the thread - thanks, but nothing new in there that I wasn't already aware of. Having coded in OOP for two decades my original confusion was one purely based on not fully understanding C# namespaces (and foolishly following NinjaTrader's recommendation of placing enums into the global namespace), which now has been remedied. My bad - we're moving on.

I am still unclear however as to why NinjaTrader would reject a clearly defined namespace with our without a class stump (abstract or otherwise) in the containing resource. In the meantime I have resorted to replicating the same stump class which inherits from NinjaTrader.Indicator. Not my favorite thing to do but I'm not willing to devote more time to figuring this out as I believe it has to do with how NT handles enum definitions in DLLs. There's apparently a bug in there but since it's not 'supported' I think we architectural purists are without a paddle on this one ;-)

Incidentally the example you provided is what I'm doing right now. However, should I ever export any indicator/strategy that uses that particular enum then I will have to include that indicator as well. My MAType was a good example of that - it's being used across several of my indicators/strategies and it would have been preferably to simply attach a DLL that had been compiled outside of NinjaTrader instead of having to include the stump indicator that contains them.

The way that I showed is just my preferred method because the namespce is self-contained in the class file, so when I export the class file, I am guaranteed to have the relevant namespace available. That way, there is no need to inherit from anything.

If you prefer you can separate all your custom namespaces into a single file, without any class code, or even with an unnecessary empty class. Of course, then you do have to include that file in any export which uses an object defined in the file, but that file need contain no code, other than the namespace definitions and contents.

The point is that you do not need to separately bind any class as an extention to NinjaTrader, in order to use a namespace that is defined in said file.

I was aware of your OOP background, so I only suggested that you read the whole thread, precisely because I thought that you are the kind of person, with enough knowledge, who would see that we really have discussed many of the nuances, even as they might differ from the implementation in Java.