Plugin loading

vvvv beta general
1

Hello,
just noticed a few bugs on the way plugins are loaded.

If you put a non .NET dll in the plugins folder, it stops the scan when it reaches the dll.

Had a look on the hoster code in subversion (Method Scan for plugins), as you might use the same technique in the main vvvv application.
{CODE(ln=>1)}plugindll = System.Reflection.Assembly.LoadFrom(dllsi);^
That should be inside the try catch , as if one dll fails to load as an assembly, it will break the loop and other assemblies won’t be loaded

{CODE(ln=>1)}if (objType.IsPublic)^
If possible it should be replaced by
{CODE(ln=>1)}if (objType.IsPublic && !objType.IsAbstract)^
So we only list concrete classes.

{CODE(ln=>1)}objInterface = objType.GetInterface(“VVVV.PluginInterfaces.V1.IPlugin”);
if (objInterface != null)

This one is not a problem, but a normally type safe way to do it is:
{CODE(ln=>1)}if (typeof(IPlugin).IsAssignableFrom(objType.GetType())

thanks
vux

2

hay vux,

thanks for the pointers, i fixed the exception catching in both vvvv and the hoster.

the public and abstract check is probably not needed at all, still i added the abstract check as you suggested. won’t hurt.

i only don’t get the last line. does it work for you exactly like that?

3

Hello joreg,

thanks for this.

For the abstract part I found when I need to do a collection of plugin nodes, which do almost the same thing,
it is easier to put the general behaviour in an abstract class implementing IPlugin, then put the specific stuff in an inherited class (so we only need to update behaviour in one place).

If you don’t put the abstract check it will appear in the node list, which we don’t want as we can’t instanciate it anyway.

For the last line, it is just a type-safe way to do the same thing, yours works as good.