Plugins in C#

[Mike D Sutton]

Hi,
I'm porting an old project over to C# which makes heavy use of plugins, however I'm not sure the way I've approached
it is the best technique.
In the old project, I had a TypeLib with the global interfaces each plugin needed to expose defined with it, then
referenced this within each plugin. In the C# version I currently have a DLL defined which simply exposes the
interfaces, and each plugin project references this file.
Is there any way of getting rid of this extra DLL and instead importing just the interface definition into each project
as with the old solution?
Cheers,

Mike


- Microsoft Visual Basic MVP -
E-Mail: (e-mail address removed)
WWW: Http://EDais.mvps.org/

 

[Nicholas Paldino [.NET/C# MVP]]

Mike,

No, there is not. If you imported the file that the interface was in
into each project, each compilation of the interface would be a new type
definition (it doesn't matter that it is the same type name, same namespace,
etc, etc), and your plug in architecture is the right way to do it.

You are doing the same thing in C# as you were doing in your old
project. You had one binary (the type library) that had the interface
definitions, and then refrenced it where you need it (from both the plug-in
implementors, and the consumers). You are doing the same thing here.

Hope this helps.

 

[Mike D Sutton]

No, there is not. If you imported the file that the interface was in into each project, each compilation of the

interface would be a new type definition (it doesn't matter that it is the same type name, same namespace, etc, etc),
and your plug in architecture is the right way to do it.

You are doing the same thing in C# as you were doing in your old project. You had one binary (the type library)
that had the interface definitions, and then refrenced it where you need it (from both the plug-in implementors, and
the consumers). You are doing the same thing here.

It's almost the same as the old project, however the TypeLib was previously only required at design time since it was
compiled into each DLL (the definitions and GUIDs were therefore the same so the various plugins could talk.) In the C#
version I have to have the DLL containing the interface definitions present at runtime also which is the bit I'm trying
to avoid if at all possible.
I've being doing some research on the matter since I first posted the query and have found a couple of references to a
COM TypeLib importer which can create a C# wrapper from an interface defined in a TypeLib. If all else fails I could
simply use my old TypeLib, wrap it and use that from each project but I was hoping for a more managed solution.
Cheers,

Mike


- Microsoft Visual Basic MVP -
E-Mail: (e-mail address removed)
WWW: Http://EDais.mvps.org/

 

[Nicholas Paldino [.NET/C# MVP]]

Mike,

I would go so far as to say that you did the wrong thing with the type
library by compiling it into the dll. Basically, you should have
distributed the type library separately, and then registered it on the
system. You had a lot of duplicated information by including it in each
plug in DLL, when in reality, you didn't need to do anything like that.

Yes, you could use the Type Library importer (TLBIMP) to import the type
library into an assembly, but that doesn't mean that you should compile
those types into every plug in. It's excessive, and quite frankly, you are
duplicating the code needlessly.

What is the reason for not distributing one assembly with the interface
definitions?

 

[Mike D Sutton]

I would go so far as to say that you did the wrong thing with the type library by compiling it into the dll.

Basically, you should have distributed the type library separately, and then registered it on the system. You had a
lot of duplicated information by including it in each plug in DLL, when in reality, you didn't need to do anything
like that.

True, however since all that was defined in the TLB were a couple of interfaces, the duplication was minimal and avoided
the requirement for the additional DLL (as well as the potential overhead of having to load it for each plugin, or was
it only loaded in the process space once? I don't recall..)
This allowed me to release the main application as a standalone executable that could be easily sent out without having
to provide an installer, then additional DLL's only as they were required - Ideal for the environment it was used in
(in-house utility.)

Yes, you could use the Type Library importer (TLBIMP) to import the type library into an assembly, but that doesn't
mean that you should compile those types into every plug in. It's excessive, and quite frankly, you are duplicating
the code needlessly.

What is the reason for not distributing one assembly with the interface definitions?

Ultimately, just one less dependency.
Point taken though, I'll just stay with the extra DLL for now, it works well enough and I've still got the rest of the
app to worry about!
One other option I've been thinking of, would it be an viable option to make each plugin reference the main application
project, and grab the plugin interface(s) from there? The plugins would never need to be run without the application
present, and that way I could still distribute the main application as a standalone EXE.
Cheers,

Mike


- Microsoft Visual Basic MVP -
E-Mail: (e-mail address removed)
WWW: Http://EDais.mvps.org/

 

[Nicholas Paldino [.NET/C# MVP]]

Mike,

See inline:

True, however since all that was defined in the TLB were a couple of
interfaces, the duplication was minimal and avoided the requirement for
the additional DLL (as well as the potential overhead of having to load it
for each plugin, or was it only loaded in the process space once? I don't
recall..)
This allowed me to release the main application as a standalone executable
that could be easily sent out without having to provide an installer, then
additional DLL's only as they were required - Ideal for the environment it
was used in (in-house utility.)

I can understand the desire for xcopy deployment. The type library
should only be loaded once in this scenario, since the GUID assigned to the
library should be the same. You just have to deal with the synchronization
issue (in case the type library changed), but I assume you have that under
control.

Ultimately, just one less dependency.
Point taken though, I'll just stay with the extra DLL for now, it works
well enough and I've still got the rest of the app to worry about!
One other option I've been thinking of, would it be an viable option to
make each plugin reference the main application project, and grab the
plugin interface(s) from there? The plugins would never need to be run
without the application present, and that way I could still distribute the
main application as a standalone EXE.
Cheers,

You could definitely do this in .NET 2.0. It allows references to EXEs
and not just DLL's. I don't know about 1.1 though.

If you keep it in a separate DLL, you won't have to worry about
distribution so much, since you can just copy the DLL with the interfaces in
it to the same directory. If it is in the same directory as the EXE, the
CLR will find it.

I have mixed feelings about referencing the EXE. On the one hand, if
the plug in interface is only going to be used by the EXE and no where else,
then it makes perfect sense.

However, you have to worry about public types exposed in the EXE, and
the access that your plug ins now have to it. You might have to redefine
your types as internal in order to protect some functionality that you don't
necessarily want your plugins to have access to.