Exporting VL DLLs and dynamic loading (eg. Plugins)

[domj]

Hi,

trying to figure out the right way to implement dynamic plugin loading of VL exported assemblies on runtime.

I’ve put together a simplish test sketch with an IPlugin interface that has a single Register method (this would register itself in some system). This is implemented by some class that is exported into a DLL to be loaded at runtime and added to the system.

Currently I’m using the System.Reflection.Assembly to load an exported DLL, sift through exported types, find one that’s implementing the interface (comparing Types), create an instance of it using the IVLFactory CreateInstance, cast it to the IPlugin type and call the method.

This seems to work but there are a few caveats/questions:

• To get the IPlugin interface I have to reference the exported DLL and not the IPlugin.vl document. I guess this makes sense as they can be considered different assemblies.
  However my issue is following: Suddenly the interface is called IPlugin_I in a new IPlugin namespace and all of its output pins have a suffix _Out, making Output into Output_Out, which reduces readability. Also it means changing a lot of old code if I switch to precompiled DLLs for interfaces. This will I think also apply to any VL types the interface might be using. They will have to be exported after every change (losing on the fly development) and their names will differ. Is this the right way to export and use VL libraries or is there a better way that retains the original VL behavior? Or is something planned in the future?
• There are initializers inside the exported documents, containing the RegisterServices method that deals with registering types, serializers(?) and possibly other things into VL.
  Is this something I should call myself when loading the libraries like this or is it done automatically? Since the CreateInstance and GetTypeByName calls work, I’d assume everything is in order. Is there something I should keep in mind when loading VL libraries like this though?
• The exported VL documents have unnecessary dependencies (for a library) and the lib also seems to contain a lot of ballast, but I guess you plan to deal with this once the main .exe export is working well.

Patch available here Transfer - Dropbox

[gregsn]

@domj

However my issue is following: Suddenly the interface is called IPlugin_I in a new IPlugin namespace and all of its output pins have a suffix _Out, making Output into Output_Out, which reduces readability.

Try to define the interface in C# and only implement it in VL.

[domj]

@gregsn

Try to define the interface in C# and only implement it in VL.

I have considered that and indeed in this example it would work well enough.

In practice I use custom VL types in my interfaces. Therefore I would have to export these to DLLs to reference them in C#, running into similar issues.

Also in general I think VL should function as a full development environment and switching between VS and VL breaks this whole magical experience you’re pioneering so it should be avoided whenever possible.

[gregsn]

you are of course totally right. So basically all we can do is to be open and communicate the state of the system. And while it is able to export more and more applications, it’s just not ready for dll export yet.

[domj]

I don’t think you mentioned DLL compilation in any other place than when regarding startup speed of 2019.2. It was always about exe export, so I don’t think you’re deceiving or anything, although it never hurts to be more clear.

I’m just personally quite interested so I was investigating as it is already technically feasible and trying to bring possible issues forth.

I wish VL to become much more popular and I do believe that it being able to produce libraries that play well with the rest of .NET is a key part of that. If you’re getting a nuget you don’t really have to care if it was implemented in C# or VB, it should be similar with VL.