Exporting Compiled Assembly 3rd Party Load Failure

[johnMoss]

I've run into this problem in the past on the receiving end. Now I'm generating the problem ...

Objective: Export a group of Indicators into a single one-shot Importable zip folder; i.e. the usual...

1) There a total of 27 indicators in the package. 15 of these are system indicators, and 12 are non-system indicators.

2) Of the non-system indicators, there are only 3 in which I'm interested in compiling as dynamic link libraries, If the others remained as open-source .cs, that would be ideal.

3) So far, on the first shot, I deliberately added all required indicators to the Export window and selected the compiled assembly option.

4) This compiled just fine.

5) On attempting to load onto a 3rd party computer, it was rejected with the standard Import failure window due to the existence of one of the potential conflicts. I suspect duplicate method is the issue.

6) For S&G's, I attempted to load into my own system and also generated a failure.

7) Re-attempting the export procedure precisely as above but without selecting 'Export as Compiled Assembly', export worked as expected and 3rd party installation using the ninjascript zip import feature was also successful without incident.

Questions:

1) Is the issue because I'm manually selecting system indicators to be included? Need I deliberately not manually select them & allow the system to recognize them and add them in its own way?

2) Revisiting Item 2 above, There are only three of the proprietary indicators I'm actually interested in keeping in .dll format. If the others remained accessible as .cs files, that would be good.

3) The issue is that in choosing the three I'm actually interested in keeping as reference files, if the compiled assembly option is selected and you don't purposefully select the other required non-system indicator components, Export will fail under the causality rule of ' [please] add missing components.

4) Where me go wrong??

Happy Friday Ya'll

JM

[QuantKey_Bruce]

In general, you don't need to add system indicators and it will do this on its own if they are determined to be dependencies. I have seen some cases where they must be selected manually but this is not the usual case.

The thing to understand is you can't create a compiled DLL without including all of the necessary references.

So, let's say you have Indic1, Indic2, Indic3, and Strat1, and Strat1 uses Indic1, Indic2, and Indic3, you can't make Indic1, Indic2, and Indic3 open source and then make a compiled assembly of Strat1 because Strat1 will necessarily include Indic1, Indic2, and Indic3 in its export, and if the destination computer has Indic1, Indic2 and Indic3 as open source, they will be conflicts.

So, what you could do in this example situation is save Indic1, Indic2, and Indic3 as new names e.g. Indic1Open, Indic2Open, Indic3Open, and let them have the source code to those, while the Strat1 will include Indic1, Indic2, Indic3 in its compiled assembly with no conflicts.

This is just to give you an idea how it works. Your situation may be a little different but this should get you onto a track.

[johnMoss]

Copy that, I'll give it a run... Bruce I appreciate your responses as I've moved along. Wanna have a chat w/ you on the phone. I'll be reaching out through your site...
JM

[QuantKey_Bruce]

You're welcome. Sounds like you've made lots of progress.

[johnMoss]

Also, in reference to your answer, is it more than just the file name; i.e I need alter the the public class as well?

[QuantKey_Bruce]

Yes, the class name is actually the only part that matters. The filename can be whatever, although it's a good idea to make it the same as the class name to avoid confusion and to make the most of how the tools work since that is what they expect.

[johnMoss]

Right-O... Thank you and last question: Is there a way to have the NinjaTrader software ignore the placement of this new "replacement" indicator such that it does not show up in the visible indicator choices?

Reason:

1) Several of the supporting indicators are in-house creations and open-source; meaning that that proprietary User-Interface options such as SMA settings, Momentum, etc. are all accessible and functional for strategy use as well as the chart also. Indicators which are set up as reference files (.dll) however are still visible in the strategy builder if plots have been assigned but in fact the strategy will ignore any user changes to parameter settings and actually only use the default settings. Again, Users can change User interface parameter settings and immediately see their changes on a chart, but Strategy Builder will ignore these changes in actual use and only use the default settings in conditional arguments. I want for users to be able to alter these settings for their own evaluative purposes. And if it matters yes, I do understand the system will ignore recreations of system indicators.

2) Creating new classes; easy enough. A problem arises in the form of user confusion if an indicator shows up in their chart indicators that they don't know what it is or if it's a simple rename of something, Lets say User already has an indicator called "Squeeze". Indicator "Squeeze" was used in the backend construct of this new .dll download and now they open up their Indicator choice window from a chart and discover they of course still have their original "Squeeze" indicator but now they have a "Squeeze1" showing up also.

In this case the objective is to avoid confusion. In the scenario I've just created here, both are accessible to the chart, they both do the same thing, but one is adjustable in Strategy Builder, but the copy I included is not.

So trying to avoid both clutter and confusion... So again, Is it possible to have the system ignore placing the similar but compiled indicator as a choice in the indicators window? I know I can leave name blank but that simply creates an oddball empty space in the Indicators window..

Thanx Again
JM

[QuantKey_Bruce]

If Strategy Builder is ignoring their settings it sounds like the input parameter properties are not set up right...

One approach to keeping them separated is to have a namespace e.g. JohnMossProductions and put all the real stuff in there (so they show up in Indicators -> JohnMossProductions) and then put the extra stuff e.g. with source code for their info in another namespace e.g. JohnMossSourceCode.

In this way, they won't be next to each other in the list - they'll have to drill into the folder they want to get what they want.

Or, if you don't want the source code versions to run at all, you could just give them the source code files and don't install them. That would put the renaming etc. on them to do.

[johnMoss]

Got it...good call thank you sir... I sent you a contact request thru your site.