NT8 Compiler - AssemblyVersion and AssemblyFileVersion required

[MicroTrends]

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...

#

Scenario 1
i test the scenario for derived/based class is not affected by code signing post compile without a strong name or by version number changes

Scenario 2
There is only 1 deployed version of A... side by side to the others...
the version is incremented... the dll is deployed and replaces the old version

The dlls that used to depend on version 1 now error when loading in NT indicators list etc

the question is if this is code signing or not doing it... i will find out

VS
briefly can you say how we can do that in VS?
are you saying that i have completely missed the fact we can compile it in VS?
or are you saying we edit the DDL by openinng in VS and setting the properties there?

Alternatives
a. its possible to add a dll to the GAC - messy installation
b. its possible to create a subfolder and deploy dlls of a different version and then bind/map the dll path or reference it - doable i would think
c. change the name of the file with each release and version...

[MicroTrends]

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.

we code sign at installer and dll payload level - this can be skipped to just the installer if code signing dlls was the culprit

A. there is only 1 dll file side by side - it can be updated and released with a new version no
B.Always things are backwards compatible unless code breaking changes are put in then recompikle is neccessary yes - or a branch of the dll to new name yes
C. we want 1 common file to many assemblies etc... 1 code base.... keeping older versions side bu side with prior products in subfolders could work... i guess if NT could load them from subfolders...

I will test the original scenario... unless you say NT8 now works with VS better then NT7 etc

NT8
For NT8 but you say VS can be used - yet how as DLL property editor or you mean use the compiler?

[NinjaTrader_Dierk]

>> are you saying that i have completely missed the fact we can compile it in VS?

What I'm saying is that - after all - this is a just a set of C# files compiled in a VS project. You e.g. could setup your own VS assembly project, add a reference to NinjaTrader.Custom.dll, change whatever settings you liked (including signing, which - again - I advise against to stay clear of trouble) and go from there. You even could implement your own installer for your product(s). I personally have not tried that. Nevertheless, this is a way which is doable/workable.

However, at this time I can not offer any guidance for that, since their is no documentation on that subject and our priority is getting bugs and issues out of our way which would impact the majority of our user base.

[MicroTrends]

>> are you saying that i have completely missed the fact we can compile it in VS?

What I'm saying is that - after all - this is a just a set of C# files compiled in a VS project. You e.g. could setup your own VS assembly project, add a reference to NinjaTrader.Custom.dll, change whatever settings you liked (including signing, which - again - I advise against to stay clear of trouble) and go from there. You even could implement your own installer for your product(s). I personally have not tried that. Nevertheless, this is a way which is doable/workable.

However, at this time I can not offer any guidance for that, since their is no documentation on that subject and our priority is getting bugs and issues out of our way which would impact the majority of our user base.

1. We compile in NinjaTrader - import into NinjaTrader - take the DLLS and .cs and yes use our own installer and deploy to get around the issues with NT importing and to provide settings and templates also as payload.

2.What we have found with NT is that it is limiting our process by not offering the two version numbers... AFAIK... due to the fact you update both instead of just the assembly so i will go on to try to show that or to show it was something else such as code signing the dlls after NinjaTrader export etc.. or maybe someone did change a public method or property or something.....!!!!!!

3. With NT we use it as a code editor and to explore the object model etc... we never were able to compile with it in NT7... but will have a look in NT8 again

4. VS offers a way to edit DLLS directly and set properties i have not done this either

Thank you for your time

[koganam]

>> are you saying that i have completely missed the fact we can compile it in VS?

What I'm saying is that - after all - this is a just a set of C# files compiled in a VS project. You e.g. could setup your own VS assembly project, add a reference to NinjaTrader.Custom.dll, change whatever settings you liked (including signing, which - again - I advise against to stay clear of trouble) and go from there. You even could implement your own installer for your product(s). I personally have not tried that. Nevertheless, this is a way which is doable/workable.

However, at this time I can not offer any guidance for that, since their is no documentation on that subject and our priority is getting bugs and issues out of our way which would impact the majority of our user base.

Maybe I misunderstand.

Are you saying that in NT8, the integration with VS is such that we can just compile directly in VS, without worrying about the NT wrapper code, which was the problem and reason why in NT7, even after editing in an external editor, we still had to run the compilation from inside an NT7 file loaded in the NT7 code-editor?

[NinjaTrader_Dierk]

If the wrapper code is the issue then you always could code a 'dummy' implementation of your indicator in NT, make NT create the wrapper code and manually copy the wrapper code to your own project/installer etc. True for NT7 and NT8.

Just take a look at NinjaTrader.Vendor.cs (wrapper for NinjaTrader.Vender.dll which is several indicators): it's no different. It requires manual work, yes, but you could do what you want.

[koganam]

If the wrapper code is the issue then you always could code a 'dummy' implementation of your indicator in NT, make NT create the wrapper code and manually copy the wrapper code to your own project/installer etc. True for NT7 and NT8.

Just take a look at NinjaTrader.Vendor.cs (wrapper for NinjaTrader.Vender.dll which is several indicators): it's no different. It requires manual work, yes, but you could do what you want.

Which pretty much is what we used to do, so no real change other than being able to directly launch and load in VS from NT8. Still pretty useful ability though. Thanks.

[MicroTrends]

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.

i have just conducted multiple tests... i took working assemblies - recompiled incremented them and all was ok...

i must conclude from them that in the past the increment of the version numbers was not the cause of the fail to load module message - it must have been code breaking changes... is the only other alternative.. must be something public had changed on the old API - a property a method signature...something... possibly declarative property tags - a code compare would be the answer in the future if that occured during testing etc

The code signing added to the DLLs post compile had no affect at all - which is good news.

so i apologise profusely then for the misinformation and over keeness at pursuing this...
the fault must lay in code breaking changes...afterall...

[koganam]

i have just conducted multiple tests... i took working assemblies - recompiled incremented them and all was ok...

i must conclude from them that in the past the increment of the version numbers was not the cause of the fail to load module message - it must have been code breaking changes... is the only other alternative.. must be something public had changed on the old API - a property a method signature...something... possibly declarative property tags - a code compare would be the answer in the future if that occured during testing etc

The code signing added to the DLLs post compile had no affect at all - which is good news.

so i apologise profusely then for the misinformation and over keeness at pursuing this...
the fault must lay in code breaking changes...afterall...

I am glad that you have that sorted out.

I still want to be able to from the NT export be able to add description and copyright information. Just as I asked for 4 years ago.

[MicroTrends]

I am glad that you have that sorted out.

I still want to be able to from the NT export be able to add description and copyright information. Just as I asked for 4 years ago.

Good news they are considering that one also in another thread... let hope i think Bret will push that one