For a long time, we have used VB6 activex dlls as our plugin strategy for our application. Works great. Now we want to include dotnet assemblys. We are working on the strategy to create objects for the plugins (late-binding-esk). I have the file path of each plugin, and have figured out how to create an assembly object, look for the correct interface, instantiate and run. All works fine.
My problem is how to develop and debug these DotNet plugins. In the past, we ran the application on our development machines, started VB6, opened the plugin's project file and started the debugger. Since COM used the programid, VB6's IDE overrides any plugin DLL installed on the machine. When the application does a CreateObject(progid), it jumps right to the IDE in debug mode, instead of creating an object from the classes in the DLL.
I would like a similar 'convenience' for plugin developers using dot net. The problem is that the dot net object creation scheme outlined above involves going right to the files in the plugin folder. I can open the IDE, open the plugin project, attach to the main application's process. But when the application creates the object from the type found in the files, of course, the IDE does not intercept it, and the DLL provides the class instead of the debugger.
Anyone have a suggestion?