Plugin system


I created a pull request for this:
I created a command line option that allows you to give a folder that contains plugin assemblies.
These will then be loaded and all classes can then be used in your Train script.

I am also thinking about scanning the Train.exe folder and loading all assemblies in that folder as well. That way you can include assemblies on your system all the time without having to add a command line option.
The commandline option is still usable for project specific assemblies.

Best Regards,


I approved the merge req, however I think it does still need some work. ATM it depends on matching the version of Script and Train exactly (as you need those to link to). I’m wondering if there’s a way we can do this without doing that.

Does the resulting assembly contain info about the version of Train and Script?
So the resulting dll is not loaded by a newer version of Train, or it is only not loaded if the Interface specs changed?

i’d also suggest using naming convention for Plugin dlls that are auto-loaded from the Train.exe folder, so we dont just randomly load in any dll that might be sitting there.

Jeroen: Yep; It’s because of how .NET links to dlls.

Would it work if we extract all the needed plugin interfaces into a separate project?

marc: What do you have in mind? a custom extension? like

yeah that could work, but it’s version nr/public key couldn’t change.

either a custom extension or a custom prefix:


ck said: yeah that could work, but it's version nr/public key couldn't change.
that'd suck as well.

Another option is putting all api functionality in a dictionary and only using func/actions.

How would that work then?

actually I think I have a better idea:

just got to be careful for any interface changes.

great solution!