Does "Protect compiled assembly" change class/method names in each compilation?

[manugarc]

Dear support team and users (if someone is using this software and may share his experience, it would be great too):

Since I develop strategies which share a number of common libraries/imports, each time I export one of them to an another NT in which I have already imported another one, NT show the error message complaining about same class/methods names are contained in the new import and so, it can't be done.

In order to get rid of this, I think that using the software which provides SecureTeam would be a possible solution since I guess it changes classes and methods names in each invocation, each compilation. However, they say they "can't guarantee it", and I don't know if it means they (or the person who has replied to me) don't know it for sure or it is just that while being a random process, they literally can't be 100% sure about no classes/methods names are going to be repeated. If latter, I would be still interested, because I don't mind having to compile some strategy/indicator from time to time when errors arises, but in the case they always use the same names, no matter how many times one compiles it, obviously it wouldn't solve the problem at all.

Any experience on it? Anyone?

Thanks in advance.

[NinjaTrader_Jim]

Hello manugarc,

Thanks for your post.

As I understand, renaming is a feature included in Agile.NET, and I would assume that this process is random to make it more secure which would be why they could not make a guarantee here.

I would like to ask, though, if you include your dependencies in one export, and then include a reference for that assembly with any exports that would need this dependency, could you work around this issue? This would force the user to import the dependency first, and then they could import the main product assembly that uses this dependency. References can be included in an export by selecting Types > References in the Export window.

I look forward to being of further assistance.

[manugarc]

Hello manugarc,

Thanks for your post.

As I understand, renaming is a feature included in Agile.NET, and I would assume that this process is random to make it more secure which would be why they could not make a guarantee here.

Hi Jim, thanks to you!

I do understand the same, but since I don't have confirmation on their side and price goes up from the stated 100$ to the 135$ when you start the buying process, I want to be sure, since this is the main purpose I want to use this software for.

I would like to ask, though, if you include your dependencies in one export, and then include a reference for that assembly with any exports that would need this dependency, could you work around this issue? This would force the user to import the dependency first, and then they could import the main product assembly that uses this dependency. References can be included in an export by selecting Types > References in the Export window.

I look forward to being of further assistance.

Hmmmmm. I didn't think about this option. Sounds pretty good!! Let me give it a try between today and tomorrow and I'll come back with the results.

[manugarc]

Hi Jim,

I strongly believe your solution may be perfect for my needs and I would like to make it work; however I am facing some problems I can't solve. This is what I'm trying to do and the problem I'm having:

0) Let's say I have 2 strategies (s1, s2) which use a number of common (custom) libraries/classes (c1, c2, c3) and I want to export on one side c1, c2 and c3 as an independent compiled assembly, as suggested, and on the other side, s1 and s2 (each one in its own compiled assembly)

1) I export as compiled assembly c1, c2 and c3 (all of them in the same assembly "c123")

2) I try to export strategy s1, and I add to the assembly the very s1 strategy and the c123's dll which is contained in the c123.zip file (I guess this is the way it should be done)

The problem I'm facing is that NT complains about functions on c123 which take parameters of type "Strategy", saying that:

error cs1503 [...] 'NinjaTrader.NinjaScript.Strategies.S1' cannot be converted to 'NinjaTrader.NinjaScript.Strategies.Strategy'

This happens in functions contained in c1 which are like:

public static void logout(Strategy parent, String txt){

    [...]

}

But I do not get this error when compiling the "old way"/all together. I don't know why does it happens or how could I solve it. Any idea?

[NinjaTrader_Jim]

Hello manugarc,

Thanks for writing back.

Could you let me know if you see this issue when using a dynamic type instead of Strategy? We have some notes advising this for DrawingTools and the issue looks similar.

https://ninjatrader.com/support/helpGuides/nt8/en-us/considerations_for_compiled_assemblies.htm

If the issue persists, could you email me at platformsupport [at] ninjatrader [dot] com with a small test package that I could use to set up and look into on my end? Please include the ticket ID 2235988 along with a link to this thread, and the text Attn Jim.

[manugarc]

Hello manugarc,

Thanks for writing back.

Could you let me know if you see this issue when using a dynamic type instead of Strategy? We have some notes advising this for DrawingTools and the issue looks similar.

https://ninjatrader.com/support/help...assemblies.htm

If the issue persists, could you email me at platformsupport [at] ninjatrader [dot] com with a small test package that I could use to set up and look into on my end? Please include the ticket ID 2235988 along with a link to this thread, and the text Attn Jim.

Hi Jim,

Using dynamic type instead of Strategy seems to do the trick perfectly, THANKS!

And regarding to use custom libraries (not custom indicators) as references in each compiled assembly works perfectly.

The problem I'm facing now is when it comes to custom indicators used by several strategies when these indicators use in turn generic indicators such as SMA, Bollinger, etc.

The detailed scenario is this one:

Multiple custom strategies (s1, s2, s3) which use (all of them) a custom indicator (ci1), which in turn uses multiple generic indicators (i1, i2, i3).

I.e:

- s1 uses ci1
ci1 uses i1 (SMA, for example)
ci1 uses i2 (Bollinger, for example)

- s2 uses ci1
...
...

- s3 uses ci1
...
...

In order to do this, I need to compile ci1 as a separated assembly to be referenced by all s1, s2 and s3 (please correct me if this is not the way I'm supposed to do it), but when I try to do that, I can't (or I do not know how to) tell NT8 to not include SMA.cs or Bollinger.cs into the assembly, and doing so, when I try to import it in another NT8, I get the message telling me SMA.cs or Bollinger.cs already exists.

I've even tried to add every existing reference to the ci1 assembly, trying to get NT8 not to add SMA.cs or Bollinger.cs to the assembly, but I can't; I always get the message
"The following file(s) will be included in the NinjaScript Archive File since they are required by one or more of your selected export files: @Bollinger.cs, @SMA.cs ...".

For what it's worth, in my custom indicator ci1, the way I use Bollinger is just by declaring a class variable into the custom indicator just like this:

private Bollinger indiBollinger;

And then, into OnStateChange() -> [...] if (State == State.DataLoaded), I create the instance just like this:

indiBollinger = Bollinger(2, 20);

Should I do it in any other way to be able to avoid having to add those indicators (Bollinger, SMA...) to the assembly since they are obviously going to already exist in the NT8 where I want to import my custom indicator along with the strategies which use it?

Sorry for the length of the message; I just tried to make it as clear as possible how I am trying to do it so you could see whether I am doing something wrong.

Thanks in advance!!


UPDATE:

Trying to do it as explained in this post:

https://ninjatrader.com/support/forum/forum/ninjatrader-8/strategy-development/107205-error-compiling-export-assembly-how-to-solve-log-included

The problem seems to be when exporting the very Bollinger, because it uses SMA.cs. Is there any way of asking NT8 to not include SMA for Bollinger as a dependency but as plain text or something like that, in order to avoid these conflicts?

Even when adding SMA.cs as "System indicator", I'm getting this error message:

2019-09-10 14:47:10:607|2|4|Error compiling export assembly: c:\Users\Ninja\Documents\NinjaTrader 8\bin\Custom\Indicators\@Bollinger.cs(37,11) : error CS0433: El tipo 'NinjaTrader.NinjaScript.Indicators.SMA' existe tanto en 'c:\NT8_Common\MyCommonLibrary3_1.dll' como en 'c:\Users\Ninja\Documents\NinjaTrader 8\bin\Custom\NinjaTrader.Vendor.dll'

[NinjaTrader_Jim]

Hello manugarc,

Thanks for the reply.

Could you email me a barebones test package that I can put together on my end that will demonstrate this specific issue?

Please email me at platformsupport [at] ninjatrader [dot] com and include the ticket ID "2235988" along with a link to this thread, and the text "Attn Jim."

I look forward to assisting.