NT8 Compiler - AssemblyVersion and AssemblyFileVersion required

[MicroTrends]

When you export a compiled assembly from NT - it uses the version number for all assembly properties and does not allow you to chose.

We need to control the versions
[assembly: AssemblyVersion("2.0.0.0")] - main
[assembly: AssemblyFileVersion("2.0.50727.3521")]
[assembly: AssemblyInformationalVersion("2.0.50727.3521")]

We need something like this:http://screencast.com/t/7UgNRge3


With this in mind:
The moral is that if you’re shipping assemblies that other developers are going to be referencing, you need to be extremely careful about when you do (and don’t) change the AssemblyVersion of those assemblies. Any changes to the AssemblyVersion will mean that application developers will either have to re-compile against the new version (to update those AssemblyRef entries) or use assembly binding redirects to manually override the binding.
1. Do not change the AssemblyVersion for a servicing release which is intended to be backwards compatible.
2. Do change the AssemblyVersion for a release that you know has breaking changes.
What about if we can control what to change for isntance can we control some of this with the NT8 compiler

[NinjaTrader_Dierk]

Same thing as here:

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

Several years back we researched pros and cons and came to the conclusion that the best way for us and our partners is not deal with version number management. I personally am not aware of a single case in the past where a partner actually would have run in an issue which our approach.

[koganam]

When you export a compiled assembly from NT - it uses the version number for all assembly properties and does not allow you to chose.

We need to control the versions
[assembly: AssemblyVersion("2.0.0.0")] - main
[assembly: AssemblyFileVersion("2.0.50727.3521")]
[assembly: AssemblyInformationalVersion("2.0.50727.3521")]

We need something like this:http://screencast.com/t/7UgNRge3


With this in mind:
The moral is that if you’re shipping assemblies that other developers are going to be referencing, you need to be extremely careful about when you do (and don’t) change the AssemblyVersion of those assemblies. Any changes to the AssemblyVersion will mean that application developers will either have to re-compile against the new version (to update those AssemblyRef entries) or use assembly binding redirects to manually override the binding.
1. Do not change the AssemblyVersion for a servicing release which is intended to be backwards compatible.
2. Do change the AssemblyVersion for a release that you know has breaking changes.
What about if we can control what to change for isntance can we control some of this with the NT8 compiler

I asked for that way back in the NT7 times, about 4 years ago.

ref: http://www.ninjatrader.com/support/f...ad.php?t=44354

I am not sure if they even bothered to put it in their tracking system, as I failed to followup to get a posted tracking number.

[MicroTrends]

Same thing as here:

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

Several years back we researched pros and cons and came to the conclusion that the best way for us and our partners is not deal with version number management. I personally am not aware of a single case in the past where a partner actually would have run in an issue which our approach.

I understand you did that years ago - and you certainly didn't ask me then - and for some reason are not aware of my lobbying of certain features to make your tech even better and the best it can be for developers... That was years ago this is now. This is the perfect time to ask the right person who uses that feature and needs for vital reasons a tiny additional field... :-)

This is very important for several reasons already stated i am sure you as a developer should understand about that - but maybe i have not presented the problem correctly?

Ok let’s recap and put it this way we are a top tier NinjaTrader consultant and partner and i am reporting to you that this is a huge issue for us in the past and now... and our clients... i am not sure why you would not have had this report in the past... we are woking on NT8 was the reply for the last 3 years or so... so now we can do it as you still working on NT8... So now you have a direct case of this.. you cannot say you dont know of one...but...

Are you saying you don't understand the importance and impact of it?
if you want to see video evidence of the impact or do not understand i can arrange this very easily... simply NT will fail to load the assembly... as the compiled assembly looking for version n of assembly b will not find it side by side... because both version properties were updated instead of one...

Regardless of the past horrors we had dealing with this - going forwards we need to be as professional as possible and incrementing the right version number is essential for us when exporting a DLL to prevent all the crazy recompiling, installer building, code signing, updating and $1000s of overheads you cause over the year for us and other clients... We and others like us bring in to NT, commercial funds and you need to help us do our job...in a saturated market and help widespread adoption over all other trade platforms...for retail too... this really does help that...

Please consider who NT is catering for? Quality professionals who will help the adoption of your trade platform by commercials enough to use in their funds…and bring their volume... Surely you want to promote longevity and the best patterns to allow commercial developers to help take it to the next level? so please add that -

Alternatives:
Can we compile in visual Studio or via a C# script or via an API Call into NT code editor and specify it there?

i look forward to your repl... such is the importance of this to you and commercial developers like us - we need to unite on this please

Please let me know if you want to see walk through of this awful problem this omission causes us


many thanks

Tom

[NinjaTrader_Dierk]

>> as the compiled assembly looking for version n of assembly b will not find it side by side

What exact issue do you experience? Can you pls provide a scenario where our current approach would fail? Thanks

[MicroTrends]

I asked for that way back in the NT7 times, about 4 years ago.

ref: http://www.ninjatrader.com/support/f...ad.php?t=44354

I am not sure if they even bothered to put it in their tracking system, as I failed to followup to get a posted tracking number.

Ok great please can you help me convince them as this is really a huge deal - it is a nightmare! :-) it really is

[koganam]

Ok great please can you help me convince them as this is really a huge deal - it is a nightmare! :-) it really is

Frankly, I gave up on it, because it looked like I was the only one looking for it, and at the time I was not even an official partner.

With your addition to the fold, it still looks like there are only 2 developers looking for it. I am not very hopeful, unless we can get a whole bunch of other developers involved.

[MicroTrends]

>> as the compiled assembly looking for version n of assembly b will not find it side by side

What exact issue do you experience? Can you pls provide a scenario where our current approach would fail? Thanks

Ok sure: Your system forces the update of both version numbers of the DLL.

http://screencast.com/t/5FiPb6GQv

Resulting in this

http://screencast.com/t/LdJ4Xx0WkotW

Imagine you have a utility.common.dll - that is used by mutliple assemblies loaded by NT at startup - some assemblies are compiled against a version number only... so changing that in the past cause NT7 to fail to load the module - an error failed to load module - some kind of reflection load error will pop up....
when for example you are iterating through the Strategy list. This was found in the past...so we then have to recompile all assemblies/products and send out when we update 1 common library or foundation...

So what we need is this - the ability to control what is changed

http://screencast.com/t/WJoYrvput

2 version numbers can be seen and can be set giving that control

[NinjaTrader_Dierk]

Sorry, I'm still not following.

Let me try to understand with a simple as possible (I think) scenario:
- you as a NT partner code an assembly A
- that assembly is a 'base assembly' for your products B (which consist of assembly B) and your product C (which consists of assembly C). You may or may not market products B and C separately to you discretion
- none of the assemblies A, B, C are signed, the version number of those assemblies actually is irrelevant (AFAIK, pls correct me if I'm wrong)

Where in scenario above would there then be a problem?

[MicroTrends]

Sorry, I'm still not following.

Let me try to understand with a simple as possible (I think) scenario:
- you as a NT partner code an assembly A
- that assembly is a 'base assembly' for your products B (which consist of assembly B) and your product C (which consists of assembly C). You may or may not market products B and C separately to you discretion
- none of the assemblies A, B, C are signed, the version number of those assemblies actually is irrelevant (AFAIK, pls correct me if I'm wrong)
Where in scenario above would there then be a problem?

Well that is one scenario - however A is code signed...and B and C seperately in time,.
So on the above might be ok.. one would think as its a base class derived scenario... there are other scenarios to look at...

But to Recap so we are on same page.
We are agreed on the fact your app does not offer a way to set the version seperately, it does it at same time? Where as a commercial programming tool such as Visual Studio allows you to set one or both? http://screencast.com/t/WJoYrvput

2.The reason is this AFAIK:
1. Do not change the AssemblyVersion for a servicing release which is intended to be backwards compatible.
2. Do change the AssemblyVersion for a release that you know has breaking changes.

Scenario where code breakages occured in the past with NT7

1# MT.NT7.Common.Dll version 1.0.0.0
Containing some proprietary methods and multiple public global, singleton, sealed and maybe some abstract classes... was referenced and compiled into the following assmblies

2# SomeVendor1.NT7.Indicators
which reference and use namespace and classes/ methods in the code - accesses some globals and instanstiate and sets a readonly set of properties which provide some usage for update iunfo, settings, licenses and user data - some class extensions, enums... from #1

Compiled in reference for MT.NT7.Common.Dll version 1.0.0.0

3# SomeVendor2.NT7.Strategies
which reference and use namespace and classes/ methods in the code -
loads and sets a configuration class which then calls a webservice for license and update info and program data user settings for example..... from #1 and use indicators from #2

Compiled in reference for MT.NT7.Common.Dll version 1.0.0.0


Change MT.NT7.Common.Dll version 2.0.0.0
overwrite MT.NT7.Common.Dll version 1.0.0.0
restart - load chart and enumerate strategies = boom.... module failed to load the dependency popup error in NT on the chart

recompile all DLLS to use MT.NT7.Common.Dll version 2.0.0.0
restart.. all good

i can make some videos of this issue in action we had it with
BluewaveTradiing and woodies and our own stuff at some point
however ti will take time as i got to get various versions from code vaults and set up a test on a vps etc...


i have not experienced this error for a long time as we found by recompiling all it remove the issue... so assuming the version was the issue etc... so i will need to setup a scenario and record it failt etc.....

i would love to be wrong on all accounts and apologise prefusely

[NinjaTrader_Dierk]

Are we in agreement
a) that my scenario (and any variation of it) will not raise any issue if the assemblies are not signed?
b) that you always could implement signed assemblies including version numbers etc. at any complication level you liked by using VisualStudio instead of the NT assembly building/export process?

[MicroTrends]

Are we in agreement that when not signing assemblies then there will be no problem?

not yet but i will try that scenario as follows

so
Scenario A1...
#1 MT.Nt7.common.ddl
Compiled version 1.0.0.1
Code Certficate signed after compilation - would not add a strong name AFAIK ?

#2 SomeVendor1.NT7.Indicators.dll
reference and compiled against #1

#3 SomeVendor1.NT7.Strategy.dll
reference and compiled against #2 and #1

Scenario a2..
#1 MT.Nt7.common.ddl
Compiled version 1.0.0.2
Code Certficate signed after compilation

#2 and #3 blow up or work???? internally in NT when enumerating indicators/strategy list etc

Scenario a3..
#1 MT.Nt7.common.ddl
Compiled version 1.0.0.2
No signing
#2 and #3 blow up or work???? internally in NT when enumerating indicators/strategy list etc



Scenario b1...
#1 MT.Nt7.common.ddl
Compiled version 1.0.0.1

#2 SomeVendor1.NT7.Indicators.dll
reference and compiled against #1

#3 SomeVendor1.NT7.Strategy.dll
reference and compiled against #2 and #1

Scenario b2..
#1 MT.Nt7.common.ddl
Compiled version 1.0.0.2
No signing
#2 and #3 blow up or work???? internally in NT when enumerating indicators/strategy list etc

Scenario b3..
#1 MT.Nt7.common.ddl
Compiled version 1.0.0.2
Code Certficate signed after compilation

#2 and #3 blow up or work???? internally in NT when enumerating indicators/strategy list etc

[MicroTrends]

Are we in agreement
a) that my scenario (and any variation of it) will not raise any issue if the assemblies are not signed?
b) that you always could implement signed assemblies including version numbers etc. at any complication level you liked by using VisualStudio instead of the NT assembly building/export process?

For - A the jury is still out to lunch

For B -that was one question... ok so we can we do that?
B1 ie by compiling in VS?
B2 or by openind the DDL and writing the versions explicitly?
If so then all good ignore this whole thread... can you provide details on B?


C. if code signing the dlls is an issue we can skip that and make sure the installer is
will get back to you -

[NinjaTrader_Dierk]

not yet but i will try that scenario as follows

so
Scenario A1...
#1 MT.Nt7.common.ddl
Compiled version 1.0.0.1
Code Certficate signed after compilation - would not add a strong name AFAIK ?

#2 SomeVendor1.NT7.Indicators.dll
reference and compiled against #1

#3 SomeVendor1.NT7.Strategy.dll
reference and compiled against #2 and #1

Scenario a2..
#1 MT.Nt7.common.ddl
Compiled version 1.0.0.2
Code Certficate signed after compilation

#2 and #3 blow up or work???? internally in NT when enumerating indicators/strategy list etc

Scenario a3..
#1 MT.Nt7.common.ddl
Compiled version 1.0.0.2
No signing
#2 and #3 blow up or work???? internally in NT when enumerating indicators/strategy list etc



Scenario b1...
#1 MT.Nt7.common.ddl
Compiled version 1.0.0.1

#2 SomeVendor1.NT7.Indicators.dll
reference and compiled against #1

#3 SomeVendor1.NT7.Strategy.dll
reference and compiled against #2 and #1

Scenario b2..
#1 MT.Nt7.common.ddl
Compiled version 1.0.0.2
No signing
#2 and #3 blow up or work???? internally in NT when enumerating indicators/strategy list etc

Scenario b3..
#1 MT.Nt7.common.ddl
Compiled version 1.0.0.2
Code Certficate signed after compilation

#2 and #3 blow up or work???? internally in NT when enumerating indicators/strategy list etc

The scenario where you have different versions of A is not covered by NT (I personally have not got a single request in all these years). However, you always should be able to achieve that by using VS instead of NT. I have not tried that though...

[NinjaTrader_Dierk]

For - A the jury is still out to lunch

For B -that was one question... ok so we can we do that?
B1 ie by compiling in VS?
B2 or by openind the DDL and writing the versions explicitly?
If so then all good ignore this whole thread... can you provide details on B?


C. if code signing the dlls is an issue we can skip that and make sure the installer is
will get back to you -

Not sure I understand:
a) as per before: the NT building process does not support different versions of the same assembly
b) however, would you find that your product C (which you implemented after your product B) would need a new method/logic in assembly A, then just add it to A (pls make sure to not change/remove existing methods/properties/classes etc.) and deploy the new version of A (let's call it A2) together with your product C. Product B then still will work using A2.