best practices with shared enum

[e-man]

i have a couple indicators that share a common enum. everything works great (as per the reference sample on enums that Josh wrote) until you compile one of those indicators to a DLL.

i know the easy-sleazy work around is to "clone" the enum, rename it so it's unique, and put the unique version it in the specific indicator cs file ... but ...
that got me wondering if there was a better/cleaner way to do this.

ideally, i would like to create an enum and have it available to both open-source and compiled-DLL assemblies. any thoughts?

cheers,
-e

[NinjaTrader_Bertrand]

e-man, have you already tried putting this enum in it's own cs / namespace?

[e-man]

i have tried putting it in a separate cs. i copied the UserDefinedMethods.cs and pasted it at the bottom. this works fantastic as long as i didn't export to a DLL. that's when i ran into problems.

i also experimented with renaming the cs file and putting an @ in front of the name (i know, bad unsupported idea, but i was just curious to see if the compiler and export features would react differently; however, the result was the same error).

i have not tried creating a separate namespace. i was hoping for the simple/quick approach, but perhaps this warrants something more involved.

cheers,
-e

[NinjaTrader_JoshP]

e-man,

If you do not want to worry about exporting them as DLLs without including the file that actually has the enum definition I suggest you just create unique enums for each of your scripts. It may be redundant, but it removes the dependency on the other scripts so you can export them individually.

[e-man]

josh - thanks for the reply. that's exactly what i've resorted to doing. and it works great!

from what i can tell, the export was picking up the dependency on the other cs file and (i presume) incorporating it into the DLL. everything would work fine if that was the only indicator utilizing the enum cs imported to a ninja installation. but if i another indicator (not to DLL) also depended on the enum cs was imported, it would throw errors.

not sure if that makes sense or not. but from what i can tell, the DLL'd version doesn't play nicely with an open-source version and visa-versa when they both depend on that enum cs file. whichever one gets imported first succeeds, but the second attempted import fails.

i just assumed this was either a known limitation or by-design. i haven't tried the other suggestion of creating a separate namespace, but i wonder if it would have the same result when mixing DLLs and open-source imports.

cheers,
-e