Automating the Uninstalling/Removing of Prior Versions of AddOns

[jeronymite]

The ability to Import a NinjaScript Assembly and include additional files in a template folder is great. Thanks!

The need for a custom installer is virtually eliminated if one uses the first run of the product to identify a new install (or an update) and take appropriate actions. This is essentially a "built-in" installation-completer/updater in the product. Very simple and easily supported for new installations and updates.

One consideration though is how one may automate the full removal of prior versions, either when an update is made or a full uninstall is requested. The DLLs sit in the bin\Custom folder, but is it as simple as merely deleting the DLL and corresponding CS files?

What is the recommended approach to automating the removal of prior versions of AddOns when updating, and, if requested, fully uninstalling AddOns?

Thanks.

[NinjaTrader_Kate]

Hello jeronymite,

Thank you for your post.

There's not a supported way to do this through NinjaScript we could recommend though it would certainly be possible to use unsupported methods to remove previous versions. When we manually uninstall a compiled assembly, we remove the .cs and .dll files from the Custom folder and also remove the reference from Config.xml. So you'd need something that would delete the reference from Config.xml as well as deleting the files themselves.

Please let us know if we may be of further assistance to you.

[jeronymite]

Thanks, Kate.

Deleting the .cs and .dll files is (relatively) straightforward. For the Config.xml file, I note that there appear to be two places that are relevant:

• The AddOnRegistry section that has the AddOnAuthorization entry for the AddOn
• The References section that includes a reference for the .dll (or possibly .dlls in the case of multiple versions)

Would you confirm/correct the following, please:

• For an upgrade, remove all relevant .dll References except for the latest version, but do not remove the AddOnAuthorization itself.
• For an uninstall, remove all relevant .dll References and the AddOnAuthorization.

Some questions:

• Is the Config.xml file editable when NinjaTrader is running (file open/sharing permissions), and can it be updated by an AddOn and have those changes persisted across a NinjaTrader shutdown/restart? Or will NinjaTrader rewrite the file at shutdown with internally saved data that will essentially recreate the deleted records?
• How should one treat the AddOnRegistry section in the case of an uninstall when the AddOn is the only AddOn registered? Should one remove the entire section?
• What actions, if any, would be required to eliminate the live AddOn in an uninstall, other than removing it from the ControlCenter menus? Presumably, an AddOn attempting to delete its own .dll would fail due to it being in use? If that is so, how would one automate that, other than with a separate AddOn, and even then, would it be able to delete the file?
• If a number of versions of .dll files exist (prior versions and current version), how does NinjaTrader treat the prior versions? Are they "live" and do they have any effects? Is there effectively a "cascade" of versions running simultaneously? For example, would the OnWindowCreated methods of all versions be run, rather than just the latest version only?

May I request more work in this area, please, to provide fully supported ways to do the following:

• Install/upgrade/uninstall AddOns in a consistent manner
• Provide mechanisms that allow those processes to be effected by the AddOn itself or by a separate AddOn
• Allow deliberately running multiple versions simultaneously, or not, as defined by the relevant product's supported offerings [This may already be the case, by default, in the current way things work?]

Many thanks for enhancing the current already useful functionality.

Thanks.

[NinjaTrader_Kate]

Hello jeronymite,

Thank you for your reply.

The Config.xml file is not written to unless something is saved. The AddOnRegistry section is pretty much what controls the "Do you want to authorize this indicator" message that pops up when installing an add-on. I would suggest removing the reference from there as well so the user must authorize the new version to be run.

The actions that must be done to remove the add-on would be to delete the existing .dll and .cs files and removing the reference. This would likely be unable to be done from the Add-on itself. Automating that would be out of the scope of our support.

All .dll files within Custom will be compiled if left in place. If they have the same class names as other .dlls then there will be a compile error. You can have as many versions of a script as you want as long as they all have unique class names and appropriate references in the Config.xml file.

We have a supported way of removing an add on via Tools > Remove NinjaScript assembly, and for consistency and simplicity would advise simply having users uninstall a previous version of the assembly prior to upgrading unless the new assemblies have unique class names and can therefore be compiled together.

Please let us know if we may be of further assistance to you.