<p>I’m looking at rewriting a portion of our application in C# (currently legacy VB6 code). The module I am starting with is responsible for importing data from a variety of systems into our database.  About 5-6 times a year, a new client asks us to write a new import for the system that they use. Presently, this requires us to release a new version of our software for each new import option we add to the application. </p>

<p>One of the goals of the rewrite is to make the application support plug-ins. Every new import can become a separate assembly which the host application will recognize and allow the end user to interact with.  This will hopefully simplify life to some degree as we can simply drop a new assembly into the directory and have it be recognized and used by the main (host) application.</p>

<p>One of the items I am struggling with relates to the differences between the import options we currently support. In some cases we actually let the user point to a directory and read all of the files within the directory into our system. In other cases we allow them to point to a single file and import its contents. Additionally, some imports have a date range restriction that the user applies while others do not.</p>

<p>My question is, how can I design the application in a manner that allows for some flexibility among the imports we build and support while at the same time implementing a common interface that will allow the host application to easily recognize the plug-ins and the options that each one exposes to the user?</p>

[{'answer_id': 46308, 'author': 'David Mohundro', 'author_id': 4570, 'author_profile': 'https://Stackoverflow.com/users/4570', 'pm_score': 3, 'selected': True, 'text': '<p>I would recommend you take a look at the Managed Add-In Framework that shipped with .NET 3.5. The <a href="http://blogs.msdn.com/clraddins/" rel="nofollow noreferrer">Add-In team</a> has posted some samples and tools at <a href="http://www.codeplex.com/clraddins" rel="nofollow noreferrer">CodePlex site</a> as well..</p>\n'}, {'answer_id': 46309, 'author': 'Joel Coehoorn', 'author_id': 3043, 'author_profile': 'https://Stackoverflow.com/users/3043', 'pm_score': 1, 'selected': False, 'text': '<p>.Net 3.5 has the system.Addin namespace.</p>\n\n<p>This thread also has some good information for older versions of the framework:<br>\nh<a href="http://forums.devshed.com/net-development-87/system-plugin-532149.html" rel="nofollow noreferrer">ttp://forums.devshed.com/net-development-87/system-plugin-532149.html</a></p>\n'}, {'answer_id': 46312, 'author': 'Vitor Silva', 'author_id': 1842864, 'author_profile': 'https://Stackoverflow.com/users/1842864', 'pm_score': 1, 'selected': False, 'text': '<p>for the theory take a look at the <a href="http://www.martinfowler.com/eaaCatalog/plugin.html" rel="nofollow noreferrer">plugin pattern</a> in martin fowlers Patterns of Enterprise Application Architecture</p>\n\n<p>for an interesting example take a look at this tutorial: <a href="http://www.codeproject.com/KB/cs/c__plugin_architecture.aspx" rel="nofollow noreferrer">Plugin Architecture using C#</a></p>\n'}]
['https://Stackoverflow.com/questions/46292', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/2833/']