Circular dependency solution?
-
I have a main application that is referenced by a plugin. I would like the plugin assembly to be copied into the main application folder. Currently I have to do it manually because VS.net will not allow me to add a circular dependency. Any solutions?
-
I have a main application that is referenced by a plugin. I would like the plugin assembly to be copied into the main application folder. Currently I have to do it manually because VS.net will not allow me to add a circular dependency. Any solutions?
The solution is a simple logical solution: a plugin should typically not have a dependency on the application that hosts it, but perhaps a shared assembly that the application uses. Having the plugin depend on the application itself makes your design very inflexible. Worse yet, never have a dependency on your plugin. The whole idea of plugins is that they can be added or removed from your application (either before executing it or while executing it) without the application knowing about it. This is where polymorphism comes into play. You either use interfaces or abstract classes declared in a shared assembly that plugins reference. They extend the abstract class and/or implement the required interfaces. Your application communicates with the plugins through these classes or interfaces without knowledge of the actual implementation. This is the entire fundation of COM, .NET (a progression of COM, but not a replacement), web services, and many other technologies. All communication is done through a common interface (also called a "contract") so that the implementation is hidden. That's a true plugin. These plugins could be loaded from the .config file (common in .NET applications), some other file or the registry (which COM uses, but is not recommended for .NET code for deployment reasons), or even enumerated in a directory and loaded. There are many articles here on CodeProject that discuss various implementations of plug-in system. Just try a search for "plug-ins" or something similar.
Microsoft MVP, Visual C# My Articles
-
The solution is a simple logical solution: a plugin should typically not have a dependency on the application that hosts it, but perhaps a shared assembly that the application uses. Having the plugin depend on the application itself makes your design very inflexible. Worse yet, never have a dependency on your plugin. The whole idea of plugins is that they can be added or removed from your application (either before executing it or while executing it) without the application knowing about it. This is where polymorphism comes into play. You either use interfaces or abstract classes declared in a shared assembly that plugins reference. They extend the abstract class and/or implement the required interfaces. Your application communicates with the plugins through these classes or interfaces without knowledge of the actual implementation. This is the entire fundation of COM, .NET (a progression of COM, but not a replacement), web services, and many other technologies. All communication is done through a common interface (also called a "contract") so that the implementation is hidden. That's a true plugin. These plugins could be loaded from the .config file (common in .NET applications), some other file or the registry (which COM uses, but is not recommended for .NET code for deployment reasons), or even enumerated in a directory and loaded. There are many articles here on CodeProject that discuss various implementations of plug-in system. Just try a search for "plug-ins" or something similar.
Microsoft MVP, Visual C# My Articles
I understand all of that. It's just the way I worded it. My solution: create an xml files that holds the plugins currently in use. For plugin paths just use the existing file structure without copying the files to the local directory. I admit I should not have been working for the 18 hour that day.
-
I understand all of that. It's just the way I worded it. My solution: create an xml files that holds the plugins currently in use. For plugin paths just use the existing file structure without copying the files to the local directory. I admit I should not have been working for the 18 hour that day.
Why not have the plugin simply implement a delegate/event? The main application would add a handler for that event. Each time the event is caught, the main app could make a call into the plugin. Hence the plugin would initiate a call from the main app.