Integrating legacy application with new functionality

We have a legacy application with, among other things, the ability to create instances classes within VB6 DLLs dynamically and call methods with varying signatures.

We have no way of accessing the legacy application's code and no way of removing it from production right now.

Our requirement is to build small plugin-type applications that would be called by the legacy application. These applications have historically been written in VB6 but there is a push to create newer ones in .NET while reusing existing VB6 code where feasible, using encapsulation to hide the VB6 implementation which will eventually be replaced.

So far I've discovered that the .NET applications can be created without issue by making them COM visible with some boiler plate code.

The things I can control are the parameters being passed into the new applications and their signatures.

I would like any new applications to bypass the boilerplate, the architecture becoming:

Legacy app > new .NET application > new DLLs

One possibility I've come up with is to have the legacy application pass the assembly and class name as a parameter and a json/xml object containing the parameters that the target class would need as another parameter. The new application would then instantiate DLLs as needed using reflection.

The alternative would be to create the .NET applications in a similar way to the VB6 ones, with a parameterless constructor and a method serving as an entry point.

To draw a picture, imagine the legacy application as a datagrid, containing maybe a row id and the target apps needing the row id to do whatever they need to do.

How does this design sound? With longevity in mind, the .NET applications will be designed with reusability in mind from the start. I'm slightly worried that if / when the legacy application is phased out we'll be left with a poor architecture as a result of how things need to be done now.

Also, am I missing anything obvious here?